I have been giving Youness's reply some thought. On 29/09/2018, Peter Stuge <pe...@stuge.se> wrote: > Youness Alaoui wrote: >> On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper <sam.ku...@uclmail.net> wrote: >>> Relevant URL: >>> https://www.chromium.org/chromium-os/ec-development#TOC-Write-Protect >> >> We don't have/use ChromeEC and I think that telling every user that >> they'd need dedicated hardware to update their BIOS makes no sense. > > I think you can decide what hardware your products include, right? I > meant dedicated hardware on the mainboard.
I think Youness's point, essentially, was that with: - Heads running from the ROM chip; and - suitable secrets sealed in the TPM; and - additional suitable secrets sealed in a Nitrokey; any additional dedicated hardware on the motherboard would be unnecessary in order to achieve: - a "secure", pre-OS environment in which to upgrade Heads; and - a way to prevent the OS from flashing the ROM. (Youness, please correct me if I misunderstood you.) That is all good stuff, and I want it to be achieved. However, I don't think it goes far enough. I know that several Chromebooks, as described at the URL above, include a hardware switch (typically implemented as a screw or bolt acting as a *latching* SPST switch) that allows ROM flashing to be enabled/disabled. This seems to me a step in the right direction, but I don't think it goes far enough, either. Personally, I would prefer that, in addition to the Heads approach, a hardware switch should be present, but unlike on the Chromebooks it should be a *momentary* switch that stays in the write-protect position by default, and that has to be held in the write-enable position in order for the flashing process to be able to begin. (Essentially, a "dead man's handle" or fail-safe.) This mitigates two potential attack vectors: 1. a user, after she sets her Chromebook-style latching hardware switch to write-enable and flashes the ROM, forgets to set the hardware switch back to write-protect, leaving the ROM vulnerable; 2. a remote attacker finds a way to write a "badHeads" to the ROM from the OS.[1][2][3] >> > > Looking for a software solution is IMO like Intel trying to secure >> > > SMM. >> >> I don't see why that would be true, the software solution is pretty >> simple. You boot, you can write to the flash in a secure environment, > > Intel also considered SMM a secure environment, until they realised > that it isn't. These days I think they consider ME a secure environment. Ouch! It's unkind to liken Heads developers to ME developers... :p - Sam [1] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/3 [2] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/4 [3] https://forums.puri.sm/t/prevent-bios-being-flashed-by-root-level-attacker-without-physical-access/3786/6 -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
