Would it make the most sense to put locking option in coreboot's board-specific code, since the method varies between boards? Could a common ACPI call for it be provided that could be called by a payload or OS later if it's present?
-Matt
On Sun, Feb 17, 2019 at 8:48 PM Frank Beuth seclists@boxdan.com wrote:
On Sun, Feb 17, 2019 at 12:24:38PM +0100, Nico Huber wrote:
I'm not sure if I quite follow. You mean the locking that prevents you from installing a retrofitted coreboot? That's not a lock that prevents malware from anything (because of existing exploits). There are ways to install coreboot on such systems without external programmer. It's just sometimes a very uncomfortable, hacky way and if it fails you'll need an external programmer anyway. But nothing is too uncomfortable for crimi- nals. They just have to figure it out once and then profit per every- body's unit (not just there own unit).
I see, this explains a lot and goes a long way to resolving the original issue ("installing Coreboot makes me less secure because it enables software reflashing").
[Coreboot] offers only locking options that make sense in certain use cases.
Most of the locking options that have been discussed in this thread so far are rather hacky (often requiring writing new code) and not part of any Coreboot or related (e.g SeaBIOS) software package.
For Coreboot and related packages, you previously mentioned LOCK_SPI_FLASH_RO and some unspecified locking options in the FILO payload. Are there any others? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org