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 <[email protected]> wrote: > Hi Youness, > > On 15/10/2018, Youness Alaoui <[email protected]> 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: [email protected] > 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>
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
