On 15/10/2018, Youness Alaoui <kakaroto(a)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
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.
> 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'
> 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
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
> 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.