On 18.04.2016 19:02, David Hendricks wrote:
On Mon, Apr 18, 2016 at 8:48 AM, Trammell Hudson email@example.com 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 (VU#577140):
Flash ROM locking on S3 resume
- Don't lock ROM sections on S3 resume (LOCK_SPI_ON_RESUME_NONE) (NEW)
- Lock all flash ROM sections on S3 resume (LOCK_SPI_ON_RESUME_RO) (NEW)
- Lock and disable reads all flash ROM sections on S3 resume
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.