Boot Guard - pre-execution firmware verification on Protectli FW6

What is Boot Guard?

Boot Guard does not mean exactly what its name suggest, it is not protecting shoes. In firmware and BIOS nomenclature boot means the bootstrap process, which is the early processor initialization routine. Almost every modern machine or processor has some kind of firmware which is responsible for the bootstrap process - booting - which prepares the silicon to load the target application or operating system. So ‘Boot Guard’ quite literally protects the boot process and the firmware. But from what should it protect and why? You can find it out by spending a few minutes to read this post.

Boot + Guard

Why Boot Guard?

Nowadays security researchers are very focused on the trustworthiness, security, and hardware-level safety of the computers we use everyday. These so-called “white hat” researchers explore every possible vulnerability and attack vector in modern systems to find holes in the security of the most crucial parts of our modern systems, such as Intel ME, UEFI, and others. Conversely, the bad guys, commonly known as “black hats” are constantly trying to find new and innovative ways of gaining access to systems that are harder to detect. Traditionally, the bad guys would find bugs in browsers or network protocols that would give them root access to the operating system and allow them to then install tools to keep their access persistent. Researchers and anti-virus companies would usually detect these exploits by scanning memory or files for known virus signatures, then patch holes and cleanse infected systems. However, this game of security cat and mouse has now evolved to the point where the bad guys are looking for new and interesting ways of not only gaining access to systems, but also maintaining that access undetected. Logically, the place for malicious software to hide and stay undetected is in the part of the system that the operating system and no knowledge of or access to - the system firmware.

How do you know that software you use is trustful, secure and hasn’t been maliciously modified before execution? One can only ensure this by establishing the Root of Trust (ROT) as early as possible.

There are 2 main type of ROTs:

  • SRTM - Static Root of Trust for Measurement
  • DRTM - Dynamic Root of Trust for Measurement

We will not delve too deep into the measurement process of ROT, as it is not a part of this post, but what we will focus on here is cryptographic verification in the ROT. ROT is the beginning of the verification process, it is considered to be trusted and verifies all components executed by firmware. For DRTM it may be any time after the system has been powered on, because the processor is responsible for establishing a clean environment for ROT to begin the verification process. For SRTM it is the very early moment in the boot process. As soon as firmware sets up temporary memory, it launches an executable module responsible for establishing ROT and further firmware image verification. While this all sounds great, how can one protect this early code responsible for temporary memory setup and ROT establishment?

For more details about ROT refer to NIST.

Some details about DRTM can be found on TrenchBoot GitHub. We are also involved in DRTM development on AMD platforms and contribute actively to TrenchBoot. One may find our achievements on various conferences:

Protecting the ROT can be achieved by locking the SPI flash containing the firmware for example, however this does not protect the SPI from a desoldering attack. Attackers can actually physically solder a new SPI which can contain maliciously modified firmware which compromises the Root of Trust and even install backdoors, keyloggers, RAT’s or other malware.

In order to protect systems from even desoldering attacks, we can use Boot Guard, which verifies the early firmware code responsible for temporary memory setup and ROT establishment before the firmware is able to execute. Because of that Boot Guard is an SRTM solution.

How Boot Guard works?

Intel Boot Guard is a feature that allows firmware verification before the first instructions get executed. How was this achieved? This feature is supported by Intel ME, which instructs the processor to load an Authenticated Code Module (ACM) signed by Intel responsible for manifests validation and boot policy enforcement. During the verification process, ME utilizes the Key Manifest, Boot Policy Manifest (which is a part of Boot Guard) and the Firmware Interface Table (FIT). Before fetching the first firmware instructions, the processor searches for the FIT and applies microcode updates which are pointed by FIT. The microcode verifies the ACM, which verifies the Key Manifest, which verifies Boot Policy Manifest (so complicated right?). In the end the Boot Policy Manifest contains the hashes and signatures of the code regions in firmware that have to be protected and verified. After the firmware verification, ACM allows the processor to fetch the first instructions to be executed.

So in the event that the firmware is maliciously modified, it would not be able to execute. It would fail because the manifest that holds the firmware signing keys would fail the firmware verification. As an added step, the public key hash of the key used to sign the Key Manifest can be burned into the ME and locked permanently to ensure that no one except the key owner can change the firmware signed in the Boot Policy Manifest.

The flow described here is one of the most restrictive profiles that Boot Guard offers - strict verification without remediation. There are less restrictive profiles which allow the platform to keep running for 30 minutes if firmware verification fails in order to restore the system and flash trusted firmware. But the production behavior of Boot Guard ensures that unverified firmware cannot execute on the processor and immediately shuts the platform down.

Where can I get Boot Guard for my platform?

One has to either pay thousands of dollars to a big firmware development company to enable Boot Guard on your hardware or buy costly hardware which has Boot Guard already enabled.

That was true until now. Recently, one of our customers -Protectli - asked us to improve the security of their network focused product called the Vault by implementing Boot Guard. Protectli sells compact network devices running Intel processors and the most powerful of them have Intel processors which are Boot Guard capable. As a matter of fact, 3mdeb had previously implemented coreboot for these platforms, so implementing Boot Guard was a natural enhancement to the overall security of the system.

And today we have succeeded. The first official platform running open-source firmware that has Boot Guard enabled is here. It is possible thanks to the fact that Protectli cares about hardware security and sees value in open-source firmware and software.

Protectli logo

This first-of-its-kind platform can be seen in action at the 3mdeb booth at Embedded World 2020, but here is a brief glimpse of what you can expect to see at the Embedded World 2020 exhibition.


Boot Guard and coreboot? Yes, of course

The below asciinema video presents the Protectli FW6B platform booted with Boot Guard enabled coreboot firmware executing an Intel tool called MEInfo, which is used to dump information about system and Management Engine.


In the video, we see some interesting detail, including Boot Guard info:

  • OEM Public Key Hash FPF Not set
  • OEM Public Key Hash ME 7E8E9BF4EF2E3AC831672D0049414081EA8D32C2E36B5D69457D4E3AA0B70517
  • ACM SVN FPF 0x2
  • KM SVN FPF 0x0

The OEM Public Key Hash represents the SHA256 of the key used to verify the Key Manifest. It is located in the ME and on production devices is is burned into FPF (Field Programmable Fuses).

ACM SVN FPF describes the ACM security version, 0x2 means it is a production ACM.

KM SVN FPF is a Key Manifest security version. It is used to revoke Key Manifests. 0x0 means that no Key Manifest was revoked yet.

There are also some additional variables stored in ME:

                                             FPF                      ME
                                             ---                      --
Force Boot Guard ACM                         Not set                  Disabled
Protect BIOS Environment                     Not set                  Enabled
CPU Debugging                                Not set                  Enabled
BSP Initialization                           Not set                  Enabled
Measured Boot                                Not set                  Disabled
Verified Boot                                Not set                  Enabled
Key Manifest ID                              Not set                  0xF
Enforcement Policy                           Not set                  0x1
PTT                                          Not set                  Enabled

Force Boot Guard ACM, Measured Boot, Verified Boot and Enforcement Policy make up the Boot Guard profile.

They can be encoded as follows:

Firmware verification with Boot Guard is enabled, Enforcement Policy equal to 1 means “allow remediation”, system will shutdown after 30 minutes if firmware verification fails. Disabled Force Boot Guard ACM means that if ACM is not found in firmware, the processor will execute the code from a reset vector. If enabled, the system will shut down with a delay based on the Enforcement Policy. It must be noted that not all combinations of these fields are allowed. Only strictly defined Boot Guard profiles determine these fields' values.

Other interesting values are CPU Debugging and BSP Initialization which additionally protect the boot flow from modification via DCI or INIT signal.

Thus far, we have only seen the status of variables. However the status of successful Boot Guard firmware verification lies in the status registers:

  • FW Status Register4: 0x00084000, bit 14 is equal to one indicates that the information contained in this register is valid. Bit 9, which is zero, indicates that the enforcement has not been triggered

  • FW Status Register5: 0x00000B01, bit 31 is equal to zero, which means the chipset does not start enforcement logic. Bit 0 is equal to one and indicates that ACM is active (and of course present in firmware).

That means the system will not shutdown after 30 minutes as the Boot Guard profile instructs the processor (if verification fails).

Summing it up: Boot Guard verified the firmware successfully.


This is just a taste of what Boot Guard can do. The presented information and demonstration show non-production settings and the ME is still in Manufacturing Mode which allows the settings to be reprogrammed. It has been intentionally left enabled for further development.

I encourage you to visit the 3mdeb booth at Embedded World 2020 (25th - 27th of February 2020 in Nuremberg, Germany). There, you will be able to see the Boot Guard demo live. We will be at hall 4 - 666. Also we want to thank The European Regional Development Fund for the subsidy of the “Presentation of 3mdeb Embedded Systems Consulting software solutions for international markets” project realized by the 3mdeb Embedded Systems Consulting company.

If 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 your hardware platform, feel free to book a call with us or drop us email at contact<at>3mdeb<dot>com. If you are interested in similar content feel free to sign up for our newsletter

Michał Żygowski
Firmware Engineer with networking background. Feels comfortable with low-level development using C/C++ and assembly. Interested in advanced hardware features, security and coreboot. Core developer of coreboot. Maintainer of Braswell SoC, PC Engines, Protectli and Libretrend platforms.