When I was learning there was definitely a lack of well-documented UEFI bootloader code publicly available. As someone new to the technology, you definitely don't want to sift through ELILO to find out how Linux uses UEFI.
If I did this again, which I'm sure I will, I would not use GNU-EFI. I would use a cross-compiler to build a PE executable for the EFI executable directly, without using GNU-EFI. Still, GNU-EFI is a good place to start. It's much easier to work with than EDK2.
Forgive my self-promotion here, I feel it could be relevant to interested parties here.
I remember when UEFI became a thing and people were complaining in linux forums that the keys are controlled by the manufacturers and 'the whole thing is a ploy by microsoft to kill linux' (UEFI is just a convoluted standard way to write BIOS in a certain way).
Now we can control the keys, all we need to do is kick UEFI to the curb and use linux from BIOS all the way to the DE/WM (coreboot..).
Turns out we can turn the boot process into a chain of kexec's and simplify everything greatly.
If you want to more easily configure UEFI Secure Boot on your Linux system, while also registering your own signing keys to eliminate the Microsoft and OEM ones: https://safeboot.dev/
Having an EFI shell binary on a USB stick can be incredibly useful when you're troubleshooting boot issues. I went down this rabbit hole because the Thinkpad X1 Tablet doesn't play nice with GRUB when there's no keyboard attached, but if you setup entries directly in EFI you can select a boot partition using the touchscreen. There used to be precompiled binaries floating around in the tianocore Github repo, but it looks like the link has gone dead.
See also Pete Batard's excellent project to support all kinds of exotic filesystems in EFI.
http://efi.akeo.ie/
I remember when UEFI was about to be released, there were a lot of concerns about how this will completely block Linux installation, dual boot, etc on Windows computers. Did that problem happen? How was that solved?
What I don’t understand is, how did that not completely nullify the security promises of SecureBoot, rendering the whole exercise pointless in the end ?
> Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
Because each stage of the boot sequence is still verified:
- the root of trust is in the TPM
- by default, the initial shim stage is verified using a Microsoft cert in the native trust database, and after the shim (which has an embedded Canonical cert) loads grub, then it verifies and loads the kennel
Grub also has its own trust store it can use, if I recall.
The root of trust is not in the TPM, it's in the system firmware. On Intel, the firmware itself is verified by the Management Engine. Measurements of these roots of trust may be passed to the TPM, but the TPM isn't in a position to do much with that information other than report it back at a later point in time - otherwise firmware updates would invalidate your root of trust.
OK, I probably should have just left this as a "cryptographic co-processor" rather than TPM (or else used "a TPM"). But I believe there is some blurring here:
- My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT, which is essentially a software-implemented TPM with some extra features (so right, "system firmware"). It's true that PTT is part of the ME. But it's still a firmware-based TPM.
- With AMD, they use a cryptographic coprocessor whose name I forget but which is similar to PTT and which contains either a hardware or firmware-based TPM.
- With ARM, I'm pretty sure they use TrustZone, which is analogous to a TPM.
> My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT
No. The public keys used for verifying secure boot payloads are in the system firmware and are validated on the CPU. If you have a feature like Boot Guard enabled then the Management Engine will verify the firmware bootblock with a key that's flashed into the chipset, but that's not required by the UEFI spec and has nothing to do with PTT. Under no circumstances is the TPM used. On ARM the initial firmware validation will be carried out by the SoC, but there's no TrustZone involved.
Well, that's how Intel describes for 4th gen, and I had assumed more recent gens: "Intel Platform Protection Technology with Bootguard works with Intel PTT..." on page 8. They mention both Windows and boot protection. How does it work with Bootguard? Does that mean bootguard bootstraps PTT trust?
If you have more recent documentation, I'd be interested. It's hard to learn about this semi-internal Intel and AMD stuff.
Edit: Also, you write "with a key that's flashed into the chipset". Do you mean chipset (which could be on the motherboard) or on the CPU itself? Where do you find this information?
Bootguard isn't UEFI Secure Boot, and it works with Intel PTT in that the bootguard data is measured into the TPM. The signing keys used for Bootguard aren't in the TPM. Bootguard only protects system firmware, it does nothing to protect the ME firmware (which is where PTT lives). The flow is:
1) You apply power. The ME is powered up and reads its firmware out of flash. Most components of this firmware have signatures verified[1] and the ME then boots
2) The ME examines the state of the fuses in flash in order to determine whether to impose a Bootguard policy. If so, it verifies the signature of the firmware bootblock against a key fingerprint that's been blown into the chipset fuses. Depending on policy, a failed validation will either block the system from booting, allow the system to boot but cut power after 30 minutes (in order to allow remediation to occur) or do nothing. If the policy specifies that measurements should be performed, a measurement will be generated and pushed to the TPM (PTT, if you're using it)
3) The system firmware bootblock (running on the system CPU) will perform validation of the rest of the firmware, generating additional TPM measurements. The TPM is a passive component here - no key material is stored in the TPM, and the TPM cannot prevent boot proceeding if the signatures don't match. It's up to the firmware code itself to do that.
4) Once the firmware is up and running, it'll end up loading a bootloader. If UEFI Secure Boot is enabled, the signature on the bootloader will be verified against a set of permitted certificates stored in a UEFI variable in flash. The bootloader will be measured into PCR 4 and the certificate used will be measured into PCR 7, but again the TPM doesn't hold any key material and isn't able to block the system from booting.
5) If you're booting Windows and Bitlocker is enabled, the OS will ask the TPM to hand over the disk encryption key. The TPM will only do so if the PCR values match the policy associated with the key (usually just the value of PCR 7). This is the first time the TPM can do anything that would stop the system from booting, and also the first time we're using any key material that's in the TPM. But at this point, we're well past UEFI Secure Boot.
> Do you mean chipset (which could be on the motherboard)
Yes, otherwise you wouldn't be able to move CPUs between boards that have firmware signed by different vendors. The exception is the U and Y series mobile parts, where the chipset is on-package with the CPU. But those are only available as SMT parts, so it's less of an issue.
Very cool, that's you then that figured that out, presumably (along with your friend/colleague)? I was initially skeptical of your correction, because 99.9% of programmers have no idea how this stuff works (and I clearly don't either, in detail). But clearly you've got bona fides here.
So thank you for taking the time to explain this all to me. I've never been able to find out much published on this online by Intel.I assume you had to figure most of this out on your own through reverse engineering techniques?
Do you have any other good links on how trust is bootstrapped in modern Intel CPUs, other than your Blackhat presentation (which is very helpful, already 1/2 through)?
Have people/you figured out as much about trust is bootstrapped in AMD CPUs? I'm reading that the ME equivalent is an embedded ARM core using TrustZone? Is that right?
Thank you, again.
Edit: Knowing all that you know about what comes before TPM, and the associated vulnerabilities, do you still think hardware TPM modules are worth it for securing the OS boot process?
The UEFI spec insists on locked down - Microsoft sells features that depend on it being open, and sells them probably for much more than the value of dealing with rabid lawyers is.
The bios in my computer has a toggle for secure boot to be on or off. I've had it off the whole time and there was no effect on any OS as a result. The issue was limited to bios setups that didn't allow this to be toggled, and for those, as pointed out by another, signed shims resolved that issue.
Even without the shims, right from the start Microsoft was requiring that OEMs allow secure boot to be disabled in settings if they wanted to pass Microsoft's "Windows Certification" requirement.
First they require a lock, but also that the user gets the key. Next they require a lock, but the key may be withheld from the user. I wonder what they will require next. Their Surface RT line of laptops came without unlockable secure boot, so no alternative OS could be installed.
This is the problem with people not understanding how Secure Boot works, then reading specs that require such understanding.
For max-level compatibility with Windows 10 Enterprise, there's a requirement that owner of the device can change all the keys. It doesn't require a "disable Secure Boot" setting. Worst case, the device won't permit you to keep it in what's called "Setup Mode" without some inconvenience, however you have to be able to enter Setup Mode.
What's Setup Mode?
Setup Mode is when the PK variable (PlatformKey) is empty, effectively disabling SecureBoot. This mode exists so that you can load new PK value. According to UEFI Secure Boot spec, it's supposed to be frozen by manufacturer. However, being able to set your own one is critical to some of the Windows Enterprise features, and as such a way to enter that mode is required by Windows certification.
What you're saying is that, technical details aside, Windows 10 Enterprise certification effectively requires the ability to install alternative OSes.
Is that also true for non-Enterprise certification? Because the (dated) article implies otherwise. And it remains a fact that the Surface RT line was locked down so no-one could install an alternate OS on it without MS's permission. I don't know how much clearer MS could make their ambitions for control.
Yes, as there's no distinction for enterprise vs. non-enterprise certification. All systems that pass Windows logo certification have to be able to disable Secure Boot AND load user provided keys.[0]
If I had to guess, Microsoft locked down the Surface RT and wondered if they could get away with it, then once there was backlash and they realized that high-security environments wouldn't like it, they never spread the requirement to x86. That or antitrust fears.
Technically solved by allowing you to manage your own keys.
Just what any hobbyist wants to do to dual boot though. Sit down and read up on cryptographic signature verification! That'll make the hobby more approachable.
I actually really enjoyed learning about secure boot keys and TPMs and all when I was setting it up on my machine. Support for managing keys varies by board; some, especially older ones, don't let you do much, if at all, especially from within Linux.
With modern firmware, you can add a self-generated key pretty easily, and it's not hard to do secure boot dual boot with Linux (or even macOS if you're using OpenCore, I think!). It does require a bit of reading up though. :)
DKMS allows for drivers to be installed without breaking the kernel signature. And Ubuntu and Red Hat and Fedora are all MS-signed (as will anyone else willing to go through the process, which is really only feasible for large orgs but is mostly just bureaucracy). So most hobbists will never need to mess with mokutil.
You register an additional key, generated by you/the installer. Ubuntu automates it as part of setup, afaik Fedora doesn't but there are instructions for it. Ubuntu generates a key during installation, then requests UEFI register it as a secure boot signing key. You reboot, UEFI will verify in pre-boot that you asked for the key to be added (usually, some BIOSes let you disable this check). DKMS will use that key to sign the modules. Since the kernel gets the UEFI allowed keys from the firmware, it will see these signed modules as valid and load them.
It's not, if a kernel was built and signed that allowed unsigned modules to be loaded that key should be revoked. The way kernel module loading works with secure boot is that modules are signed via kmodsign.
I'll just repeat again what I've said a few times in comment sections on UEFI-related articles:
UEFI is not Secure Boot. Secure Boot is a feature that is implemented by UEFI-compliant systems these days, but UEFI systems originally shipped completely without the feature and it's still perfectly possible to do so.
Complaints about Secure Boot are generally valid complaints to have. Complaints about UEFI that are actually just complaints about Secure Boot are... just complaints about Secure Boot. Valid complaints about UEFI that are unrelated to Secure Boot are rare.
Google Cloud supports UEFI via secure boot, unfortunately you need to reinstall your VM from scratch to enable it if VM was not created with an OS image which didn't support this feature.
When I was learning there was definitely a lack of well-documented UEFI bootloader code publicly available. As someone new to the technology, you definitely don't want to sift through ELILO to find out how Linux uses UEFI.
If I did this again, which I'm sure I will, I would not use GNU-EFI. I would use a cross-compiler to build a PE executable for the EFI executable directly, without using GNU-EFI. Still, GNU-EFI is a good place to start. It's much easier to work with than EDK2.
Forgive my self-promotion here, I feel it could be relevant to interested parties here.
I wanted to mention the excellent HEADS project (as in the other side of TAILS): https://github.com/osresearch/heads
This talk is great: https://trmm.net/Heads_33c3
I remember when UEFI became a thing and people were complaining in linux forums that the keys are controlled by the manufacturers and 'the whole thing is a ploy by microsoft to kill linux' (UEFI is just a convoluted standard way to write BIOS in a certain way).
Now we can control the keys, all we need to do is kick UEFI to the curb and use linux from BIOS all the way to the DE/WM (coreboot..).
Turns out we can turn the boot process into a chain of kexec's and simplify everything greatly.
[0] https://en.wikipedia.org/wiki/Desktop_environment
[1] https://en.wikipedia.org/wiki/Window_manager
1: https://heads.dyne.org/about.html
See also Pete Batard's excellent project to support all kinds of exotic filesystems in EFI. http://efi.akeo.ie/
MS signed some at the start, see https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Sec... or https://wiki.debian.org/SecureBoot#Shim
> Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust - the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.
- the root of trust is in the TPM
- by default, the initial shim stage is verified using a Microsoft cert in the native trust database, and after the shim (which has an embedded Canonical cert) loads grub, then it verifies and loads the kennel
Grub also has its own trust store it can use, if I recall.
- My understanding is that the secure boot cryptographic root of trust for Intel is in the PTT, which is essentially a software-implemented TPM with some extra features (so right, "system firmware"). It's true that PTT is part of the ME. But it's still a firmware-based TPM.
- With AMD, they use a cryptographic coprocessor whose name I forget but which is similar to PTT and which contains either a hardware or firmware-based TPM.
- With ARM, I'm pretty sure they use TrustZone, which is analogous to a TPM.
But yes, I should have been clearer.
No. The public keys used for verifying secure boot payloads are in the system firmware and are validated on the CPU. If you have a feature like Boot Guard enabled then the Management Engine will verify the firmware bootblock with a key that's flashed into the chipset, but that's not required by the UEFI spec and has nothing to do with PTT. Under no circumstances is the TPM used. On ARM the initial firmware validation will be carried out by the SoC, but there's no TrustZone involved.
Have a look:
https://www.intel.com/content/dam/www/public/us/en/documents...
If you have more recent documentation, I'd be interested. It's hard to learn about this semi-internal Intel and AMD stuff.
Edit: Also, you write "with a key that's flashed into the chipset". Do you mean chipset (which could be on the motherboard) or on the CPU itself? Where do you find this information?
1) You apply power. The ME is powered up and reads its firmware out of flash. Most components of this firmware have signatures verified[1] and the ME then boots 2) The ME examines the state of the fuses in flash in order to determine whether to impose a Bootguard policy. If so, it verifies the signature of the firmware bootblock against a key fingerprint that's been blown into the chipset fuses. Depending on policy, a failed validation will either block the system from booting, allow the system to boot but cut power after 30 minutes (in order to allow remediation to occur) or do nothing. If the policy specifies that measurements should be performed, a measurement will be generated and pushed to the TPM (PTT, if you're using it) 3) The system firmware bootblock (running on the system CPU) will perform validation of the rest of the firmware, generating additional TPM measurements. The TPM is a passive component here - no key material is stored in the TPM, and the TPM cannot prevent boot proceeding if the signatures don't match. It's up to the firmware code itself to do that. 4) Once the firmware is up and running, it'll end up loading a bootloader. If UEFI Secure Boot is enabled, the signature on the bootloader will be verified against a set of permitted certificates stored in a UEFI variable in flash. The bootloader will be measured into PCR 4 and the certificate used will be measured into PCR 7, but again the TPM doesn't hold any key material and isn't able to block the system from booting. 5) If you're booting Windows and Bitlocker is enabled, the OS will ask the TPM to hand over the disk encryption key. The TPM will only do so if the PCR values match the policy associated with the key (usually just the value of PCR 7). This is the first time the TPM can do anything that would stop the system from booting, and also the first time we're using any key material that's in the TPM. But at this point, we're well past UEFI Secure Boot.
> Do you mean chipset (which could be on the motherboard)
Yes, otherwise you wouldn't be able to move CPUs between boards that have firmware signed by different vendors. The exception is the U and Y series mobile parts, where the chipset is on-package with the CPU. But those are only available as SMT parts, so it's less of an issue.
[1] The ME stores and parses some data files, which aren't verified. This resulted in https://www.blackhat.com/docs/eu-17/materials/eu-17-Goryachy...
So thank you for taking the time to explain this all to me. I've never been able to find out much published on this online by Intel.I assume you had to figure most of this out on your own through reverse engineering techniques?
Do you have any other good links on how trust is bootstrapped in modern Intel CPUs, other than your Blackhat presentation (which is very helpful, already 1/2 through)?
Have people/you figured out as much about trust is bootstrapped in AMD CPUs? I'm reading that the ME equivalent is an embedded ARM core using TrustZone? Is that right?
Thank you, again.
Edit: Knowing all that you know about what comes before TPM, and the associated vulnerabilities, do you still think hardware TPM modules are worth it for securing the OS boot process?
[1] https://www.linuxjournal.com/content/take-control-your-pc-ue...
First they require a lock, but also that the user gets the key. Next they require a lock, but the key may be withheld from the user. I wonder what they will require next. Their Surface RT line of laptops came without unlockable secure boot, so no alternative OS could be installed.
For max-level compatibility with Windows 10 Enterprise, there's a requirement that owner of the device can change all the keys. It doesn't require a "disable Secure Boot" setting. Worst case, the device won't permit you to keep it in what's called "Setup Mode" without some inconvenience, however you have to be able to enter Setup Mode.
What's Setup Mode?
Setup Mode is when the PK variable (PlatformKey) is empty, effectively disabling SecureBoot. This mode exists so that you can load new PK value. According to UEFI Secure Boot spec, it's supposed to be frozen by manufacturer. However, being able to set your own one is critical to some of the Windows Enterprise features, and as such a way to enter that mode is required by Windows certification.
Is that also true for non-Enterprise certification? Because the (dated) article implies otherwise. And it remains a fact that the Surface RT line was locked down so no-one could install an alternate OS on it without MS's permission. I don't know how much clearer MS could make their ambitions for control.
If I had to guess, Microsoft locked down the Surface RT and wondered if they could get away with it, then once there was backlash and they realized that high-security environments wouldn't like it, they never spread the requirement to x86. That or antitrust fears.
0: https://docs.microsoft.com/en-us/windows/security/informatio...
Unfortunately, we don't know for sure unless maybe someone manages to subpoena emails about that from MS. Everything else is modern kremlinology.
Just what any hobbyist wants to do to dual boot though. Sit down and read up on cryptographic signature verification! That'll make the hobby more approachable.
With modern firmware, you can add a self-generated key pretty easily, and it's not hard to do secure boot dual boot with Linux (or even macOS if you're using OpenCore, I think!). It does require a bit of reading up though. :)
how is this possible?
https://ubuntu.com/blog/how-to-sign-things-for-secure-boot
UEFI is not Secure Boot. Secure Boot is a feature that is implemented by UEFI-compliant systems these days, but UEFI systems originally shipped completely without the feature and it's still perfectly possible to do so.
Complaints about Secure Boot are generally valid complaints to have. Complaints about UEFI that are actually just complaints about Secure Boot are... just complaints about Secure Boot. Valid complaints about UEFI that are unrelated to Secure Boot are rare.