Hi Everyone!
Sorry for the 2 weeks late reply, I've read your responses, but I've been too busy and dealing with stuff and haven't had/taken the time to reply but your input was very much appreciated and not ignored! One thing to note is that this week will be my last week at Purism as I'm going on sabbatical for a few months, and I may or may not (most likely won't) come back to Purism in a few months. So this feature will probably be my last coreboot contribution (for a while at least).
I'm going to try and reply quickly to some of the comments. @Sam
This seems to imply that each time a Librem user wants to internally
flash the ROM, she would have to:
Yes, updating the flash would be a relatively complicated process which is ok, because for me and you, sure, we'd update the rom a few times a day/week, but for 90% of the users, they would either : - never do it - only do it when a new update is released and interests them, i.e: once or twice a year. So it's a complicated process (as you've outlined) but it would be far from annoying to users since most won't care or notice that all that is needed, and if they do, they won't care to have to do it so rarely. It will however, especially with cover-opening protections (either using glitter/whatever methods on screws to notice if they'd been opened, or with an EC handling a cover switch notification), that could be very helpful to increase their security.
Your assumption fails against a BadHeads attack.
Yes indeed, I wrote a proof of concept which was a Heads that would extend PCRs with the same values that coreboot did (and have a coreboot with measured boot disabled) and it passed the TOTP authentication. That's something that other possible solutions would try to mitigate (such as vboot I think).
@Nico:
You two might have different kinds of updates in mind. You don't need
a switch for every update. Well, I hadn't thought this through to be honest, but in theory you could still flash early in the boot process (in heads) if the protection bits aren't set on the flash. So using the jumper might only allow flashing within the OS itself. Or maybe if the bootblock locks its own region, maybe setting the jumpre would allow the user to flash a new root of trust only. I suppose that's where vboot comes through, and I've left Kyle to investigate all that (though he says we don't need it, but I'm starting to think he's wrong and I think he could be convinced easily enough, I'll point him to this thread which should do the trick). Anyways, I'm leaving Purism now and going on vacation so I'm not going to bother trying to wrap my head around all that.
FYI: What I'm trying to do is to improve the security for current machines, so the discussion on the jumper/etc.. is irrelevant for machines already in the hands of customers.
@ Sam :
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 :)
I didn't realize that "some chips don't obey the write-protect pin", but rather my understanding is that the write protect pin is there to say "the protected blocks are protected/not-protected according to hardware. The SPI flash (according to the datasheets I've read) can protect regions either with "don't protect" or "protected by WP#" or "protected until power-cycle". The status register bits can be written to either as volatile or non-volatile (for non volatile, you need another command iirc, and you can't do it with hardware sequencing, same for the 'protect until power cycle', which also needs to write to status-register-2 which can't be done with hardware sequencing either). So, really, a flash rom chip does obey its WP pin, it just depends on how it's set.
On Fri, Oct 5, 2018 at 6:14 AM Nico Huber nico.huber@secunet.com wrote:
Hi,
Am 05.10.18 um 08:39 schrieb Martin Kepplinger:
is there already a gerrit change you are working on this? Do plan to support / test a X230 flash chip's lock bits?
- MX25L6406E/MX25L6408E
- EN25QH64
- MX25L3206E
not about this request in particular but such flash-chip features in general: IMO, the best solution is to implement these in (lib)flashrom and integrate that into coreboot. I wouldn't say that it's wasted time to implement it in coreboot directly. But, in the long run, taking shortcuts or maintaining redundant implementations will slow the pro- ject down overall.
Nico
coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot