[coreboot] SPI controller and Lock bits

[Youness Alaoui]

On Wed, Oct 17, 2018 at 9:42 AM R S <rene.shuster at bcsemail.org> wrote:
>
> 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.
>
Thanks! I had a lot of fun, and this community is really great! I hope
we still get to work together again in the future and cross paths!

> 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.
>>
Thanks!
I understand that the criticism was never personal, and I think you
all were justified in being critical as well, but then things started
to change for the better in purism and it took time for people here
(understandably) to see that the change was not just smoke and
mirrors. I hope that with me gone, they'll find a good replacement and
they'll continue working with the coreboot community and keep moving
forward, instead of backward.
No, you or anyone else's criticism here had zero part in my decision
to leave. On the contrary, I really enjoyed working with the coreboot
community, you're all very welcoming, so thanks for that! I'm leaving
because I'm feeling close to a burnout, and I don't want to get stuck
in one, so I dropped both Purism and a second client I had, in order
to concentrate on my health and well being. The reason I might not be
coming back to Purism in the future is because they have a new
contract for employees/contractors which I disagree with and I'm not
ready to sign. It's still a draft though so if the feedback is taken
into consideration and lawyers don't reject the feedback and the final
version of the contract is acceptable to me, then I might come back.
We'll see what happens! :)



>>
>> > @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...
>>
Yeah, it might make someone not update if they realize they need to do
that, but I guess if they'd only need to do it in order to break the
root of trust and overwrite the bootblock or whatever, then that might
be good. Either way, it's better than having the WP# hard wired to VCC
as it is right now.

>> > 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).
>>
Yeah, I did that a few months ago, the PoC is rather simple but would
be hard to have in a test suite, I'm not sure.
Basically, I did 'cbmem -c | grep -i extend" to get the log which says
"extending PCR <id> with <hash>", then I rebuilt coreboot and disabled
MEASURED_BOOT, then in head's init script I just added the lines :
tpmcli pcr extend <id> -h <hash>
(more or less, can't remember the name of the command or what
arguments it needed.. I think i had to build a modified version of the
tool so i can give it directly the hash to extend with instead of a
message for it to hash)
That's all!

>> 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.
>>
I don't think there's a way to fix it without using some other method.
Currently, having Heads block any writes to the SPI flash and only
allow heads itself to update the bios after it verifies that the rom
is signed correctly, that's a good solution, but of course, it will
only prevent remote attacks or local software attacks. Anyone can
always just open the cover and use a hardware flasher to replace
everything. Hopefully with the next hardware, they'll have a way to
tell users if the cover was ever opened, and make it easier for users
(I'm hoping for a header) to have users verify their flash content
with a hardware flasher when needed/periodically.
Either way, 100% security doesn't exist in my opinion, all anyone can
do is make it so difficult, it stops being worth the trouble (or force
the attack to tailor his attack to a specific machine).

>>
>> > 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.
>>
I don't know, either way, in 2 days, it will be out of my hands :)
I've sent Kyle a link so he can read this entire thread and figure out
what needs to be done.

>>
>> >> 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.
>>
You're welcome!
You can see here :
https://www.winbond.com/resource-files/w25q64fw_revk%2007012016%20sfdp.pdf
Pages 14 to 20. Especially figure in 7.1.7

>> All best,
>>
>> Sam
>>

Thanks,
Youness.