[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 linuxboot/heads#1388

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

[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.