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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
