On Thu, Sep 27, 2018 at 10:18 PM Sam Kuper <sam.ku...@uclmail.net> wrote: > > On 28/09/2018, Peter Stuge <pe...@stuge.se> wrote: > > Youness Alaoui wrote: > >> avoid any malware writing to the flash > > > > Just disallow flash writes by the platform. Allow flash writes only > > by dedicated hardware (maybe ChromeEC?) which implements a simple and > > efficient security protocol. > > 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. > > > > Looking for a software solution is IMO like Intel trying to secure SMM. > > Hear, hear! > 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, once you decide you don't need to write to the flash, you lock it until your next reboot. > This is a pretty useful feature, and it would be nice if it weren't tied to > heads (or any payload for that matter). What about tianocore's capsule update > mechanism, as well as stuff like fwupd ? Any way to have something like a > common solution ? Tianocore is a payload, so tianocore's update mechanism is still about doing the update in the payload.. All heads is going to do is to run a script that calls flashrom (and actually use cbfstool to extract/inject the heads-specific cbfs files into the new image, such as the user's pgp keys for example, before flashing).. so it will have to be tied to heads either way. Heads is the one booting into your OS, so it can read-only lock the entire flash before the user (real or malicious) gets control. The use of heads is already tied in with the use a gpg key (nitrokey, yubikey, librem key), and you'd already need to have the key inserted (and pin valid) before it would give you access to a recovery shell, and the same can be done before it allows the flash to be updated. I hadn't thought of the use case of fwupd (which we're currently adding support for) since it wouldn't be able to flash from the OS, but I think that having the update file deosited in /boot under a specific filename and rebooting would be all that fwupd would need to do, then on the next boot, heads would find the file and suggest to the user to flash it. > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot