There are several ways to lock the flash. Two are "permanent":
* Flash descriptor permission bits in the IFD * SPI flash chip non-volatile Block Protect Bits and grounding the !WP pin
The IFD in the image that you're going to flash can be modified with ifdtool. I'm not sure of the best way to set the BP bits without an external programmer that exposes the SPI commands.
And some can be set at runtime during the boot:
* BIOS_CNTL.BIOSWE + BIOS_CNTL.BLE + BIOS_CNTL.SMM_BWP (SMM can still write parts of flash) * Protected Range Registers (PRR, not even SMM can bypass them)
In the kconfig menu you can select "Protect flash regions" or "Flash write protect during lockdown", although I'm not positive which of the runtime features it enables. Which version of coreboot are you building?
In any event, the x220 does not have Bootguard, so a proximate attacker could rewrite the flash chip contents with an external programmer regardless of these protections. Hopefully that is compatible with your threat model.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, July 15, 2019 6:19 PM, Public Email Account via coreboot coreboot@coreboot.org wrote:
Yes its sandy bridge. What is proper way to do this though. On flash descriptor (and if so, how?) or through coreboot option?
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, July 15, 2019 12:37 AM, werner.zeh@siemens.com werner.zeh@siemens.com wrote:
IIRC X220 uses Sandy Bridge. I think there is a flag somewhere in the descriptor where you can lock down your BIOS-region as read-only for the x86 host. I never have tried it but in theory this should lead to errors on every write attempt to the BIOS region therefore disabling write access to the flash from OS/flashrom. Werner
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org