-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SeaBIOS as heads payload? #718
Comments
As answered in the other tickets you opened, Heads addressed threat model is to use the TPM as early as possible to establish attestable root of trust to be able to measure coreboot itself from coreboot romstage cache, where other propositions requires all the chain to be trusted to be able to take any measurements of later steps. Here, relying in seabios using TPM to measure anything would be forward measurements, while firmware itself could have been compromised already, meaning only what is going to be trusted to launch operating system can be validated forward, not validating earlier prior stages, which are considered required to an established RoT. Heads is already criticized for not using ACM/TXT in its root of trust(coreboot being measured by the CPU so the root of trust cannot be hacked), going SEABIOS would be considered a regression to the project in that sense.
Heads is used as a static root of trust in this scenario. No unnecessary modules are in the monolitic kernel and additional modules needs to be loaded prior of use, modifying the TPM measurements by calling a insmod wrapper, which extends TPM measurements to invalidate what is later used to secure the boot process. and used in TOTP/HOTP. If the PCRs do not match, TOTP/HOTP default boot won't match and fail. Heads relies on cryptsetup, gpg2, kernel cryptomodules, lvm and kexec basically, to offer what it offers. When a user defines a boot default and decides to create a Disk Unlock Key to unlock LUKS encrypted container, the TPM measurements are used in combination with TPM measured LUKS header, sealed inside of the TPM NVRAM space, to generate a new LUKS key which is added in the LUKS header. The released key stored in password protected NVRAM space can only be released if TPM measurements are valid, LUKS header is valid and Disk Unlock Key typed to unlock NVRAM space is valid. Consequently, the default boot can only launch if the Disk Unlock Key is typed on that computer, protecting the user from video recorded LUKS passphrase being typed in public space, so that a bad actor cannot simply clone SSD in 15 minutes and decrypt content at leasure at a later time.
That may be interesting for #590
Yet again, Heads linux payload is secured by the TPM in the sense that once the user decides to drop in recovery shell to go interactive, TPM measurements are extended and TPM measurements cannot be used to launch default boot options either.
The current avenue is to drop custom patch and rely on coreboot VBOOT+Measured boot to rely on upstream coreboot in the future.
The current trust lanscape is: We have to trust firmware (currently just CBFS BIOS region, I think we need to extend that to whole SPI unlocked region, including other blobs). Then, coreboot measures also with TPM the payload, which contains the tools requires to establish the rest of the trust (sha256sum, gpg, kexec, lvm, cryptsetup... and flashrom, altogether. Else, what is telling you that the firmware you are going to upgrade to, internally, is good (good being signed, integrity validated). Then what tells you that your flashrom, that you use to go TPM-less with Nitrokey/Librem Key, was not tampered with to verify (backup and measure with precedent tools named)? TPM-less is also a stalled project ATM. Linux payload is minimally trusted right now. Like said previously:
Thanks for challenging the situation. I think other questions will be more specific and they are more then welcome! |
@mikebdp2, after reading https://trmm.net/Heads and https://trmm.net/Heads_FAQ, I do not understand your request to use SeaBIOS. Your motivation to use SeaBIOS seems to be to save space and to use it’s boot menu. But that is not the goal of the Heads project at all. Also, the main objective of SeaBIOS (“C-BIOS”) is to provide legacy BIOS services.
The main argument for a Linux payload is, that it’s the same code base as the Linux kernel you are going to start, and the GNU/Linux distribution allows to write your own scripts giving you all the flexibility you need in an environment you need. (How do you do two factor authentication with SeaBIOS.) Despite the larger code base, your LOC comparison is unsound, as the rom/boot kernel (what was the naming again?) only uses a fraction of that. Also, you are mistaken, that it’s required to update the ROM kernel often. The majority of the found security issues found in the Linux kernel, depending on the configuration, do not apply to it, so no updates are needed. Once it works, you are not supposed to update it anymore. What would be used as the boot loader in your scenario? Having said that, your use cases are of course valid, but they not align with this project. With the comments here in mind, I recommend to clarify your vision, and recommend to start a new coreboot/payload distribution for your use case. |
@paulmenzel @mikebdp2 the rest of the information pertinent is under #717. Feel free to close this ticket if your question has been answered. |
Compared to a Linux kernel which is currently used by heads, SeaBIOS has a much smaller source code/binaries - means, a significantly smaller attack surface and less space consumed in CBFS - and yet SeaBIOS supports a TPM. Linux kernel flashed into a BIOS chip as a heads payload - is quickly outdated, so the people have to choose between constantly updating it or sacrificing some security.
Also, SeaBIOS supports booting the LZMA-compressed floppy-based hobby OS like KolibriOS or FreeDOS added to CBFS, which provides some really interesting capabilities: i.e. add a KolibriOS https://kolibrios.org/ (tiny opensource OS written on ASM, with GUI and lots of apps all inside a 1.44MB) - and if it supports your Ethernet controller: you can browse the Internet with a simple web browser, or have a secure chat with your friends using a IRCC client with a custom encryption mod like http://board.kolibrios.org/viewtopic.php?t=3734 - all under a simple OS. Which doesn't suffer from the vulnerabilities of a complex OS like Linux, with SystemD (https://linux.slashdot.org/story/17/07/29/1647255/systemd-named-lamest-vendor-at-pwnie-security-awards) and - even if you choose something like Void (runit) or Artix (OpenRC) to avoid a SystemD - still many other issues.
SeaBIOS source code is relatively tiny (just ~50k code lines, compared to Linux kernel's ~27.8 million or Tianocore's ~1 million) and really easy to modify, as I've proved with some custom mods like https://review.coreboot.org/c/coreboot/+/32351
@osresearch Do you think, given that SeaBIOS supports a TPM and consumes much less space in CBFS, a custom fork of SeaBIOS with some additions could become a better payload for heads?
The text was updated successfully, but these errors were encountered: