Geeking Out with UEFI
oofhours.com
oofhours.com
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.
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.
how is this possible?
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. :)
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.