[coreboot] SPI controller and Lock bits

[Youness Alaoui]

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 at 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 at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot