[Starbook MkVI - Intel][coreboot] OSResearch Heads support?

[Hacksawfred3232]

I just wanted to know if Heads could be supported as a alternative payload for coreboot on this device? For reference, I glanced over their documentation, and it looks like it could work? But I don't want to risk bricking my laptop to test it. https://github.com/osresearch/heads

This would pair well with Qubes OS, which is now stable - somewhat. https://www.qubes-os.org/hcl/#star-labs_starbook-mk-vi_i7-1260p_integrated-graphics-iris-xe_hsf3232_r4-1

[Sean-StarLabs]

There's nothing stopping it, would just need to be ported

[Hacksawfred3232]

There's nothing stopping it, would just need to be ported

• I've noted that the latest available Coreboot version for Heads is 4.19, while we're on 8.40+.
• There is also mentions of a i386 - 32bit architecture for compiling the firmware itself. While the CPU and such is 64bit. Unless that's par for the course.
• Lastly, there is also the question of needing all regions unlocked for some of their functions. Unless that's just a Lenovo thing.

This is why I held off on trying to see if I can do the port job myself, since it looked like it could involve a lot more effort than tweaking some options and quick code patches. Anything more, and I would have to familiarize myself with both the coreboot firmware and Heads source code.

I'll post an issue on their git repo, see what would be required to port things over.

[Sean-StarLabs]

4.19 is the latest version of coreboot. 8.40 is the local version number.

I'm not familiar with heads, but unlocking all regions sounds like a terrible idea.

Mailing lists are a much better place for questions :)

[Hacksawfred3232]

4.19 is the latest version of coreboot. 8.40 is the local version number.

Just noticed that now! Thanks for the heads up.

[tlaurion]

There's nothing stopping it, would just need to be ported

@Sean-StarLabs @Hacksawfred3232 :

I updated heads ticket at https://github.com/osresearch/heads/issues/1388

Might want to contribute/collaborate there for it to happen!

[tlaurion]

unlocking all regions sounds like a terrible idea. @Sean-StarLabs

Lastly, there is also the question of needing all regions unlocked for some of their functions. Unless that's just a Lenovo thing. @Hacksawfred3232

If you are not OEM or ODM of a board, blobs redistribution is an issue, and then reflashing boards as a service is another in case you locked those regions but now realise it was an error. The real issue is measuring states, not preventing them to change. I will go through those here.

Then lifetime support planning of said board, without being ODM/OEM of that board is an issue. And then not having to have return/flash services in case locked regions need to change in the future. Let me detail those points as well.

If those blobs are available without redistribution issues on your side (OEM/ODM please redistribute), the choice is yours about locking or not those regions but I'm still not convinced it is a good idea, and I will cover that as well.

For non ODM/OEM with murky redistribution legal issues, finding a practical way to get the blobs from, extracted, stored and delivered for compilation of a ROM and use them to stitch a fully valid ROM is a challenge. Unlocking is a need considering what Heads packs into coreboot being its payload (this is not seabios or grub here. This is linuxboot variant and space constraints are a real challenge).

Heads initiated a mouvement (libreboot reuses the same concepts) for supported platforms under "maximized" flavors of board configurations to produce fully valid ROM images with extracted blobs), otherwise referred to "legacy" versions, where regions are considered locked and only BIOS region is flashed, while requiring a "two steps" initial external flashing+internal flashing, or using 1vyrain to why maximized flavor exists: one step external flashing of spi chip(s). If you choose to lock those regions for your boards, you will also be stuck later on with expected return policies to flash externally platforms for which you decided to lock those regions in the long run. True story, and it happened before: https://docs.nitrokey.com/nitropad/ubuntu/firmware-update-1.4

coreboot supported Lenovo platforms ships with a neuteurable ME, which blobs cannot be redistributed legally. The old fashioned way to flash coreboot on those devices (and newer) requires from the end user to take a backup of spi flash content, extract the blobs, neuter/disable/toggle HAP bit, put blobs into place and under coreboot config, build and flash. Heads provides those through build scripts and CircleCI downloadable artifacts in the goal of producing reproducible ROMs. Where GBE contains a static Mac address but documents to the user how to generate new config files to generate custom MAC address.

So the ME blob is downloaded from Lenovo, extracted and put in local build system to be packed through "maximized" flavors of a board. This is how Heads dodge the blobs redistribution legal issue since we are not ODM/ODM of those boards and nobody legal was able to clear that issue out (since not clearly written in legal terms: uncharted land). GBE is a generated configuration blob for Ethernet, and IFD (Intel Firmware Descriptor) is provided (unlocked) under Github tree. All of which are packed under "maximized" boards. The question still being open legally if we could "release" those ROMs as releases on github, since neutered ME is packed under ROMs, currently produced and downloadable through CircleCI for each Heads commit for 30 days. Once reproducibility of builds is totally resolved, it is still unclear if only providing hashes of ROMs would be satisfactory for everyone, where latest versions of ROMs are available. If you know a lawyer in the field that is ready to get his hands dirty, feel free to point him my way. Otherwise Heads will continue to be a rolling release, with code snapshots being releases but not ROMs for aforementioned blobs redistribution reasons.

If someone wants to modify Ethernet Mac address, that person would need to generate a valid GBE configuration blob and reflash GBE region. If newer research proves that ME can be further removed, ME region would need to be unlocked to be flashed internally. And for the BIOS region to be able to use that additionally freed ME space, the IFD would need to be unlocked as well. This is why those are unlocked. Otherwise the final user is expected to flash externally to bypass region locks, which is not most people reading this post or wondering around on github. If you read this, you might be the kind of person willing and/or already having an external programmer and willing to unbrick things going wrong.

There is nothing preventing us to relock ME region prior of flashing, but as today, "maximized" internal upgrades simply flash the whole SPI, including IFD, ME, GBE and the BIOS region, as opposed to specifying to flash only the BIOS region specified under IFD. It is also convenient to have IFD and GBE regions unlocked. Otherwise, as long as the IFD doesn't change, one could reflash an IFD locking back those regions. But would need to have a techsavvy friend to externally flash in case later on changes touch those regions. WP could go further and lock the bootblock. But that bootblock still changes under coreboot nowadays and will probably change again in the future. And soldering/unsoldering WP to GND is out of possibilities for most people so that is not an option even if the best protection available when measured boot is enforced through coreboot since most boards initiate measured boot from the bootblock. Sandy/Ivy has root of trust in bootblock which measures itself. This is a current limitation for which nothing else would do but upgrading firmware and or reflashing same firmware and externally audit images when in doubt and verifying hashes.

On newer hardware, ACM+sinit blobs can be used (more blobs I know, Haswell+) to define the IBB region without needing WP nor soldering. If the bootblock is part of the IBB, then the CPU will be responsible to take the first measurement of the IBB and will extend PCR0, which only ACM can extend. That is hardware anchored root of trust (as opposed to bootblock only), and should probably be enabled on hardware supporting it. Trust anchor is then in CPU, and as long as ACM blob loads from CPU and is signed by Intel, and that signing private key has not leaked, trust anchor is high.

One could most probably add GBE and ME regions as part of IBB and have Heads report tampering of those regions as well since PCR0 is part of sealing/unsealing operations, even if those regions are still unlocked. Question is what we tolerate here. More blobs for more security vs ownership? What is considered trustworthy and what tradeoff is done between security and ownership of a platform. This is a choice firmware providers have to make for their users. Users unfortunately do not know the details, even if important for their threat models. But its part of the possibilities today. Measured boot with trust anchors in hardware is possible and might be the best tradeoff possible if ROMs are reproducible.

Without unlocking regions, we would prevent lifelong internal upgrades of firmware considering still moving forward areas of research. By not unlocking those regions early on maximized boards, we could not have taken advantage of ME freed space (~5mb) that needs to be relegated to BIOS region for those boards to be fully ownable in initial external flashing. At the end of that process on sandy/ivy bridge, ME region is <=98kb and BIOS region for xx30 is ~11.8mb, where xx20 is ~7.8. Forgot the numbers on Haswell, but they are similar. VSS regions of ME partitions could not disable write access further more from ME to SPI (another area of actual research). As of now Haswell under coreboot still doesn't fully have native ram init and MRC blob limits the size of BIOS region. If >8mb, there is longer boot delays. That will need to be revisited once native ram init is there and MRC blob gets out of the way.

Agreed that ME and IFD could have those regions locked under IFD. Question is do we really want that or we want to know if they changed? As of today, it is a nice auditability feature to be able to use flashrom directly to flash whole SPI chip(s) with same ROM image, where ME doesn't really exist anymore (BUP only on xx20, BUP+ROMP on xx30). Reflashing internally from Heads the same firmware image (keeping settings) basically confirms from flashrom that nothing changed (would be nice if coreboot could also measure ME and GBE since those regions are unlocked, but that is another subject). If ODM/OEM, then redistribution of those blobs should not be an issue. But locking the IFD would prevent downsizing/improving later on. Best approach is then to provide ACM and sinit blobs in newer platforms, and have those under IBB and have measured boot work for us with added trust. Bonus: by doing so, you enable your board for TXT and DRTM (yes. Trenchboot).

Coming soon, platform locking enabled by coreboot, but activated only when leaving Heads just prior of the kexec call to final OS on supported platforms. That means that only Heads will be able to modify SPI content (That is the concern here!). That and having authentication from detached signature validation, preventing anyone but the owner of the machine to go into recovery shell/booting from USB/flashing operations) through user provisioned OpenGPG smartcard authentication through signing/vericiation against user's public key injected and measured in CBFS will permit to mitigate those concerns altogether.

For those coreboot supported Lenovo platforms under Heads, ME is neutered, not just deactivated per HAP bit (sandy/ivy/haswell) as opposed to newer models. Older models could have ME removed (xx20, GM45 chipset and older). Nowadays, ME (skylake+) is still in the ROM, just disabled/deactivated, where possible. ME signature scheme changed, Intel learned their lesson. Consequently we are now celebrating HAP deactivating bit, while ME is still there, sleeping with all its code present (5mb+ of non-removeable and questionable blobs).

Deeper explanations at blobs requirements of platforms at: https://github.com/osresearch/heads/issues/692

Awesome work on ME neutering/disablement and changes across chipset revisions at https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F

---

Thanks to @osresearch who started tackling into post gm45 ME practical tinkering and experiments who lead @corna to work on me_cleaner and the HAP bit discovery from @PositiveTechnologies. What's next?

[tlaurion]

How Heads uses TPM sealing and unsealing to secure firmware and OS boot components

Some users have expressed their concerns about locking or unlocking firmware regions for computers with Heads. For example, @Sean-StarLabs said:

unlocking all regions sounds like a terrible idea.

@Hacksawfred3232 said:

Lastly, there is also the question of needing all regions unlocked for some of their functions. Unless that's just a Lenovo thing.

These are some valid concerns that need to be addressed. In this comment, I will explain how Heads secures firmware and OS boot components with coreboot and TPM sealing and unsealing, and how it trusts the user to be in control.

Heads is a system that checks the firmware and the OS boot components of a computer before booting. It uses coreboot measured boot to extend PCR registers and perform remote attestation. It also uses TPM sealing and unsealing to warn the user of any tampering in the firmware or the OS boot components.

Coreboot measured boot and platform locking

• Coreboot is a free and open source software project that replaces the proprietary firmware of some computers.
• Heads uses coreboot measured boot to extend PCR registers and perform remote attestation. This means that coreboot measures each part of the firmware and extends the values into a TPM (Trusted Platform Module), which is a chip that securely stores cryptographic keys and measurements.
• The PCR values can be used to seal/unseal secrets or to attest the state of the system to a remote party.
• Heads also uses coreboot to prepare the platform locking, which prevents the OS from writing into the firmware regions and tampering with the firmware. This is done by using system management interrupts (SMIs) to trap any write attempts to the flash chip.
• Coreboot does not enforce the platform locking by itself. It leaves this task to io386, which is a utility that runs before kexecing into Linux. Io386 enforces platform locking by setting a bit in the chipset register that prevents any further writes to the flash chip.
• This way, Heads can flash upgrades to the firmware without being blocked by the lock, but the OS cannot modify the flash content.

TPM sealing and unsealing

• TPM sealing is the process of encrypting data based on certain conditions. The TPM can create a key wrapped and tied to certain platform measurements, which can be unwrapped only when those platform measurements have the same values that they had when the key was created. Decrypting the key is called unsealing.
• Heads uses TPM sealing and unsealing to warn the user of any tampering in the firmware or the OS boot components. It creates a secret key that is sealed to the TPM and used to unlock the disk encryption. The secret key is like a password that only the user knows.
• Heads stores the secret key in the TPM as TPM Disk Unlock Key and only releases it to the OS if everything is OK.
• The conditions for releasing TPM Disk Unlock Key include coreboot measurements, LUKS header, boot options, and Heads default boot related kernel modules. The LUKS header is a piece of information that tells how to decrypt the data on the disk. The boot options are hashes of the boot components on the filesystem, such as kernel, initrd, and Xen, which are signed by the user's own private key and verified against their public key fused in firmware. The Heads default boot related kernel modules are essential modules that are loaded by Heads during boot time, depending on the platform and board configuration.
• If any of these conditions are not met, it means that something has changed or been corrupted in the firmware or the OS boot components, and it could be dangerous to boot.
• Then, Heads does not release TPM Disk Unlock Key from the TPM, and the user has to type another password to unlock the encryption on the disk.
• Heads also extends the encrypted installation by adding a second slot in the LUKS header which key is generated by Heads and injected as the key to used to unseal the LUKS container from TPM Disk Unlock Key passphrase that the user chose.

User control and reownership

• Heads trusts the user to be in control. Heads does not force verified boot or boot guard, but uses measured boot and user's keys to check the system state between changes.
• Heads also supports reencrypting disks as part of the reownership wizard, which allows the user to take full control of their computer and its firmware when they receive it from an OEM or a seller. The reownership wizard guides the user through several steps, such as creating strong passphrases, validating the firmware integrity, reencrypting disks, resetting the USB security dongle, injecting a new public key into the firmware, reowning the TPM with a new passphrase, and selecting a new default boot option.

This is how Heads uses TPM sealing and unsealing to secure firmware and OS boot components. It verifies the firmware integrity before booting the OS. It also warns the user of any tampering in the OS boot components. Heads trusts the user to be in control. Heads does not force verified boot or boot guard, but uses measured boot and user's keys to check the system state between changes.