On 18.04.2016 19:02, David Hendricks wrote:
> On Mon, Apr 18, 2016 at 8:48 AM, Trammell Hudson <hudson(a)trmm.net> wrote:
>> I'm curious why this is an option, especially since it seems almost tailor
>> made to re-create the Snorlax or Prince Harming vulnerabilities
>> Flash ROM locking on S3 resume
>>> 1. Don't lock ROM sections on S3 resume (LOCK_SPI_ON_RESUME_NONE) (NEW)
>> 2. Lock all flash ROM sections on S3 resume (LOCK_SPI_ON_RESUME_RO) (NEW)
>> 3. Lock and disable reads all flash ROM sections on S3 resume
>> (LOCK_SPI_ON_RESUME_NO_ACCESS) (NEW)
> Maybe the default just needs to be changed to LOCK_SPI_ON_RESUME_RO?
> LOCK_SPI_ON_RESUME_NONE is probably intended for developers who need to
> re-flash their systems a lot and might not want to rely on external
> programmers (especially for laptop development).
>From a defense in depth perspective, LOCK_SPI_ON_RESUME_NO_ACCESS is
more dangerous than LOCK_SPI_ON_RESUME_NONE. The former provides for
perfect stealth from in-system monitoring, the latter at least gives
in-system code a chance to perform a self-check even if a self-check of
a compromised system is very hard to do correctly and sometimes not
possible at all.
That said, I do see value in LOCK_SPI_ON_RESUME_NONE because it enables
use cases like automated coreboot test systems. Speaking with my
flashrom hat on, if you want to use it to write to the main system
flash, you have to make sure any written region is not marked readonly.
Changing the default setting to LOCK_SPI_ON_RESUME_RO may be a good
choice for quite a few use cases.