Commit Graph

5 Commits

Author SHA1 Message Date
Thierry Laurion
7e679d6d68
lock_chip: update documentation for skylake+
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-10-31 10:22:48 -04:00
Thierry Laurion
eecc611d73
bin/lock_chip: Correct PR0 statement
Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-10-31 10:22:42 -04:00
Thierry Laurion
40c34453df
all scripts: replace TRACE manual strings with dynamic tracing by bash debug
Exception: scripts sourcing/calls within etc/ash_functions continues to use old TRACE functions until we switch to bash completely getting rid of ash.
This would mean getting rid of legacy boards (flash + legacy boards which do not have enough space for bash in flash boards) once and for all.

Signed-off-by: Thierry Laurion <insurgo@riseup.net>
2024-02-01 15:48:27 -05:00
Thierry Laurion
39bb6ea313
lock_chip: parametrize locking in function of board config exported config option
kexec-boot: depend on io386 presence and board config option to call lock_chip
2023-06-20 12:40:00 -04:00
persmule
3f1c76ce11
Introduce io386 to heads and use it to finalize chipset at runtime
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
2023-06-12 13:05:49 -04:00