On 02/10/2018, Nico Huber <nico.hu...@secunet.com> wrote: > Am 02.10.18 um 13:48 schrieb Sam Kuper: >> On 02/10/2018, Nico Huber <nico.hu...@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-without-physical-access/3786/3 >> >> 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-without-physical-access/3786/4 > > 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_hardware_and_choosing_a_goodbios_-_peter_stuge#webm > > 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 <pe...@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 :) -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot