mirror of
https://github.com/linuxboot/heads.git
synced 2024-12-19 21:17:55 +00:00
3f1c76ce11
On some newer platforms of intel (confirmed on nehalem, sandy/ivy bridge), coreboot after commit [2ac149d294af795710eb4bb20f093e9920604abd](https://review.coreboot.org/cgit/coreboot.git/commit/?id=2ac149d294af795710eb4bb20f093e9920604abd) registers an SMI to lockdown some registers on the chipset, as well as access to the SPI flash, optionally. The SMI will always be triggered by coreboot during S3 resume, but can be triggered by either coreboot or the payload during normal boot path. Enabling lockdown access to SPI flash will effectly write-protect it, but there is no runtime option for coreboot to control it, so letting coreboot to trigger such SMI will leave the owner of the machine lost any possibility to program the SPI flash with its own OS, and becomes a nightmare if the machine is uneasy to disassemble, so a scheme could be implement, in which the SMI to lockdown chipset and SPI flash is left for a payload to trigger, and temporarily disabling such triggering in order to program the SPI flash needs authentication. I have implemented a passcode-protected runtime-disableable lockdown with grub, described [here](https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/docs/hardened_boot/grub-for-coreboot.md#update-for-coreboot-after-commit-2ac149d294af795710eb4bb20f093e9920604abd). In order to implement a similar scheme for Heads, I wrote [io386](https://github.com/hardenedlinux/io386). With this commit, io386 will be called before entering boot routine to trigger the SMI to finalize the chipset and write protect the SPI flash at the same time. Entering recovery shell will leave the flash writable. (The authentication routine implemented in previous revisions has been split as an independent commit.) Originally proposed under PR#326 |
||
|---|---|---|
| .. | ||
| .gnupg | ||
| bin | ||
| etc | ||
| run/cryptsetup | ||
| sbin | ||
| .ash_history | ||
| init | ||
| mount-boot | ||