GRUB2 and 3mdeb minisummit 2019

In December 2019 we had pleasure to meet with Daniel Kiper GRUB maintainer, Software Developer, TrenchBoot technical leader at Oracle and conference speaker. Since we are working with GRUB2 across many commercial projects and our customers leverage it often we decided to take advantage of this relation and organize a meeting during which 3mdeb engineers and team leaders presented GRUB related topics. This blog post summarizes the discussion and creates reference point for interested parties:

Somehow ‘minisummit’ name survived since no one offered better title after publishing Qubes OS and 3mdeb ‘minisummit’ 2019 blog post.

What we discussed during our meeting with Daniel:

We also published all videos on our YouTube channel.

Redundant GRUB2 env file

The key problem mentioned during presentations are lack of integrity check in the current implementation of GRUB2, what means any corruption of environment file in GRUB may lead to boot failure that can be recovered only by manual intervention. Since in most cases GRUB2 is used as a bootloader in general purpose computers this was not a problem. Even if in reality it happens people know how to recover either through GRUB command line or live booting Linux distro.

Unfortunately, if trying to use GRUB2 in the embedded environment there is a risk of ending up with an unbootable product, which of course leads to all other problems on the vendor’s side.

We all agreed that this feature is needed in GRUB2 and if 3mdeb will get correct sponsoring from vendors using GRUB2 such support will be developed and contributed. On the other hand, some vendors assume that file corruption is so rare that they don’t want to spend additional engineering hours on such feature.

Before such support is available, there are still methods to mitigate the impact of the problem for which reference you can find in the presentation.

TPM support in GRUB2 for legacy boot mode

The key problem here is the lack of boot process integrity in non-UEFI systems. Since GRUB2 is in boot process chain also in legacy systems we wanted to continue discussion started at LPC 2019. General conclusion on Linux Plumbers Conference was that approach presented in “TCG PC Client Specific Implementation Specification for Conventional BIOS” is preferred. What in short means that BIOS should expose legacy interrupt INT 1Ah to legacy operating system for measurement purposes.

There are couple problems with that:

  • this approach is complaint with TPM1.2, no support for TPM2.0
  • GRUB2 is neither consumer or producer of INT 1Ah
  • at this point GRUB2 supports TPM only through UEFI API
  • GRUB2 should preserve interrupt handlers

Because the whole problem seems to not be so important (it affects the limited amount of hardware) we are thinking about the simplest way of having correct results. It seems that solution that has most sense is leveraging Rhode and Schwarz TrustedGRUB2 implementation.

The key assumption of Rhode and Schwarz project is that BIOS measures MBR and interrupts for measuring bootloader kernel (diskboot.img) is called from MBR. In that way measurement chain continues. Of course something has to install those interrupts, in this case it is SeaBIOS, which implemented previously mentioned TCG specification.

Addressing a lack of support for TPM2.0 through INT 1Ah seems not to be a big issue since we can hide hardware version behind SeaBIOS implementation. Bootloader just need to extend PCRs and do not use any sophisticated TPM features. This approach implies that our stack needs SeaBIOS, since we were not able to find anyone who can confirm existence of legacy BIOS or CSM with INT 1Ah support. SeaBIOS of course limit us to coreboot and QEMU based platforms.

Based on previous assumption we have to admit that GRUB2 can be only consumer of INT 1Ah API. The simplest solution for that would be to port support from TrustedGRUB2.

In previously described cases, GRUB2 is the second stage bootloader. If we would like to have GRUB2 as first stage bootloader GRUB2 should be producer of INT 1Ah API. That implies targets like:

  • *BSD booted from GRUB2 on top of Legacy BIOS/CSM without INT 1Ah
  • any system booted from GRUB2 on top of coreboot - here GRUB2 sill can be a consumer if coreboot would install INT 1Ah API what would be a little bit bizarre in light of already having that in SeaBIOS

Moreover being a producer means providing a driver for TPM communication. According to minisummit discussion producer scenario is technically possible to implement things but may be economically not feasible.

GRUB2 security features overview

During this presentation I complained a little bit about the usability of various GRUB2 security features and suggested possible extensions that could help improve the current state of GRUB2 security. Definitely documentation could be better, but this requires time and community engagement.

Most of the talk focused on how those features help coreboot based platforms. The overall adoption of security features is slow, mostly because of a lack of integration across the system components.

Python 3 support in GRUB2

Whole topic started with our talk about “CHIPSEC as coreboot payload” from OSFC2018.

CHIPSEC as coreboot payload

Our key concern here was lack of pre-OS firmware validation environment, there were some attempts in the past like UEFI support for MicroPython, but recently there seem to be no progress in the area.

We all agreed that support for Python in GRUB would be interesting from various points of view. One area that would be problematic is ownership and maintainership since Python is evolving. Keeping it up to date would be required and probably the cost time of developers. Other mentioned alternative was MicroPython since it would resolve the same problem but probably with less maintainer overhead.

AMD TrenchBoot support in GRUB2

From this presentation you can learn how to run most recent code and test it. Most of the presentation and discussion was about internals how things should be implemented and if what we did is acceptable.

General conclusion was that we have to implement DRTM specific relocator as it was done for other boot options.

This session was more like live code review, but we took the chance to discuss each aspect of TrenchBoot support for AMD in GRUB project. Most of the mentioned problems were already implemented and sent for review to grub-devel mailing list.

In long run we plan to provide frequent updates related to AMD support in TrenchBoot project. Next update is planned to FOSDEM 2020.


It was pleasure to whole 3mdeb to meet with Daniel and understand his perspective and vision of GRUB2 from community and commercial perspective. We definitely see possible synergies and hope to find resources to support GRUB bootloader.

Some may ask if GRUB2 existence is justifiable in light of Linux booting directly from UEFI and growth of projects like LinuxBoot. Our opinion is that we choose solutions that fits best for outcome we want to achieve. Amount of work, expertise and features set accumulated over 25 years of development cannot be ignores and largely simplify our lives in some cases. It may mean that it is faster and easier to use GRUB2 in some cases and in other leverage LinuxBoot or other solution.

If you need bootloader support or you think we can help in improving the security of your firmware or you looking for someone who can boost your product by leveraging advanced features of used hardware platform, feel free to book a call with us or drop us email to contact<at>3mdeb<dot>com. If you are interested in similar content feel free to sign up to our newsletter

Piotr Król
Founder and Embedded Systems Consultant at 3mdeb as well as freelance CTO of Vitro Technology and CEO of LPN Plant. Passionate about building firmware that enables advanced hardware features in modern products. Dedicated to customers that treat embedded software security and upgradeability as forethought. Open source firmware evangelist interested in platform security and trusted computing. In favor of fixed price projects with a clear definition of success.