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
On 02/10/2018, Nico Huber nico.huber@secunet.com wrote:
Am 02.10.18 um 13:48 schrieb Sam Kuper:
On 02/10/2018, Nico Huber nico.huber@secunet.com wrote:
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.
In principle, I agree. I was just trying to clarify the reason for my choice of earlier comments.
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...
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.
The putative attack bypasses the measuring. As such, I can't see why it makes any difference whether the measuring starts early (in Coreboot), or late (in Heads). Sorry if I'm misunderstanding something basic.
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.
On 02/10/2018, Peter Stuge peter@stuge.se wrote:
Indeed soldering the WP#-pin to ground is not sufficient to disable writes on any and every flash chip, but for chips where writes *can* be disabled electrically it is the key step that overrides software.
Many flash chips support a write enable policy for parts and/or all of the chip. (See status register/block protect bits in flash chip data sheets.) The WP#-pin usually controls whether software is allowed to change that policy. If the WP#-pin is connected to ground then the policy can only be changed from write-enable to write-disable, but the other way around requires disconnecting WP# from ground first. (That's what a switch would do.)
It is worth noting (I think I mentioned it in that talk) that not all chips store the policy in non-volatile memory - only some do!
Some flash chips forget the write-protect policy on reset, meaning that the WP#-pin has no effect from reset until a software-issued command sets a write-protect policy.
That's potentially a problem if something can access the flash chip before the x86 root-of-trust runs.
You are both correct that I was assuming a chip that obeys the write-protect pin regardless of the firmware. I would be surprised if Purism ordered their motherboards to be built with chips of which that is not true, but perhaps that was unduly optimistic of me. I have not attempted to check (yet).
Thank you both for your informative replies :)
Youness and others at Purism: it would be great if Purism could be sure not only to spec, but also to list on the Librem specification pages on the website, a SPI flash ROM chip that *does* obey its write-protect pin regardless of firmware. Thanks :)
-
Nico Huber -
Sam Kuper