Am 02.10.18 um 13:48 schrieb Sam Kuper:
On 02/10/2018, Nico Huber nico.huber@secunet.com wrote:
Am 02.10.18 um 11:53 schrieb Sam Kuper:
On 01/10/2018, Youness Alaoui kakaroto@kakaroto.homelinux.net wrote:
tldr; whether the effort to disable write protection is reasonable or not depends on what you want to write protect.
Agreed.
You two might have different kinds of updates in mind. You don't need a switch for every update. With a read-only root of trust, for instance, that is secured by the switch or jumper or whatever, you could still update everything else with software only. That root of trust could either verify a signature of the following firmware parts (like vboot does) or start a measuring chain or (ideally) do both.
Separating functional updates from those that change platform-ownership is a key feature of vboot. Without such separation, you'll either make owning too easy or updating too hard.
In principle, I agree. But in practice, Librems don't seem to possess this kind of separation (yet?).
The software doesn't. But it's much easier to add it later once the hardware supports it. IMHO, design decisions for future hardware should prepare for state of the art security and not the security of yesterdays soft/firmware.
As for your question earlier about someone forgetting it. I would assume that it would be easy to have the Heads menu show a big warning to the user if it's left unprotected
Your assumption fails against a BadHeads attack.
You need to tamper more than just HEADS, otherwise the attestation of the firmware (e.g. via TOTP or a Librem Key) would fail.
That was not my understanding.
See this outline of a putative "BadHeads" attack: https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-w...
Also see Kyle Rankin's apparent confirmation that such attacks succeed (on current Librems): https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-w...
If I was mistaken about this, then I apologise.
Sorry, I won't have the time to read through all this. In theory, it depends on when the measuring is started. If the measuring starts only late in HEADS (and not in coreboot), you are right. Generally you'd have to tamper the piece of software that starts the measuring.
But... there are technical pitfalls that leave the same problem for a momentary switch: Unless you use real custom chips, you'll have to use the access protection current chips support and in the case of SPI NOR flashes there usually is no simple on/off signal that tells the chip to deny writes. Usually, you only signal it to protect its write-protection configuration which you could forget to set correctly after flashing too.
Does this mean that Peter Stuge's suggestion to (de-)solder a typical SPI flash chip's write-protect pin was erroneous?
https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271830_-_hardening_...
No, I wouldn't think so (without watching that video). What I meant is that lifting your finger from a momentary switch won't be enough. You, or the software you use, could still "forget" other things with the same effect. The problem is that what the flash chip does when the /WP pin is asserted usually depends on the chip's configuration (that you might have to change to be able to flash; depends on the chip I guess). Just read your chip's datasheet if you want to know the whole story.
Nico