[coreboot] SPI controller and Lock bits

[R S]

Yes, thanks Youness for all the hard work and research. You provided an
exceptional service. I enjoyed your rants and explanations both on Purism's
blog and here. Hopefully Purism can fill that void you are leaving behind.

On Tue, Oct 16, 2018 at 7:45 PM Sam Kuper <sam.kuper at uclmail.net> wrote:

> Hi Youness,
>
> On 15/10/2018, Youness Alaoui <kakaroto at kakaroto.homelinux.net> wrote:
> > 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.
>
> Thank you for your efforts to make Coreboot work on the Librems, and
> for the enthusiasm you displayed here in the mailing list and on the
> Purism blog.
>
> Although I might have sounded critical on occasion, this was never
> personal; it was always out of a concern to avoid missing
> opportunities to achieve the most secure and privacy-protecting
> machines available within the constraints of the hardware and the
> business model. I.e. my "criticisms" were always intended to be
> constructive. I hope that they did not form any part of your decision
> to take a break from Purism, and if they did, I apologise.
>
> I wish you a good sabbatical, in any case.
>
>
> > @Sam
> > for 90% of the users, they would either :
> > - never [flash the ROM]
> > - only do it when a new update is released and interests them, i.e:
> > once or twice a year.
> > So [...] 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.
>
> I fear that even performed rarely, it might be beyond some users'
> abilities. But...
>
> > 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.
>
> ... I agree that making it tamper-evident is indeed potentially valuable.
>
>
> >> 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.
>
> Many thanks for confirming this to the mailing list. I was hoping to
> write and somehow disseminate (e.g. to the Heads developers) a POC
> myself, but I'm glad to be spared that need.
>
> If you could send your POC to the Heads team for integration into the
> test suite, that would be great. This flaw in Heads needs to be fixed
> (if it hasn't already been). Having the POC in the test suite would
> also help to detect future regressions, once the issue is fixed (if it
> *can* be fixed).
>
> If it hasn't yet been fixed... Thinking aloud: as a community, we need
> to find a way (or else, determine that it really is impossible) to
> achieve robust mutual authentication between PC and user, with just an
> SPI ROM and a boot disk and a TPM and a TOTP/challenge-response token.
> Some kind of formal verification might be in order.
>
>
> > That's something that other possible solutions would
> > try to mitigate (such as vboot I think).
>
> In the open world, vboot does seem to be the state of the art.
>
> Apple's T2 chip might also mitigate against this sort of thing,
> although it does not authenticate to the user via TOTP: the check is
> implicit rather than explicit. I may be wrong, though. Public
> documentation seems to be scarce.
>
>
> >> 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.
>
> Thanks for this. I clearly need to spend more time reading data sheets
> and running tests on SPI flash ROM chips.
>
> All best,
>
> Sam
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>


-- 
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign <http://comicsanscriminal.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181017/06c28b62/attachment.html>