<avph> KaKaRoTo: does purism have any plans on using vboot btw?
<KaKaRoTo> avph, I'm not familiar with it, so I never looked into it. I was asked that same question last week and I opened this task for it : https://tracker.pureos.net/T315
<KaKaRoTo> it's mostly about "what is it? what is it for? do we need it? can we enable it ? etc..."
<KaKaRoTo> avph, so if you're familiar with vboot and want to give us some pointers on that, I'd appreciate it
<nico_h> mostly for a secure update mechanism
<nico_h> so not every malware can write to the flash chip
<avph> well it won't run the malware mostly :)
<nico_h> um, scratch the latter
<KaKaRoTo> nico_h, how does it achieve it? needs a portion of the flash to be read-only, no ? does it use an IFD region for that ?
<KaKaRoTo> does it require a TPM or is it a way to get verified boot without TPM ?
<nico_h> Google uses the write-protection feature and /WP pin of the flash chips
<nico_h> I'm not sure if it requires a TPM (I think only for downgrade protections or something)
<avph> KaKaRoTo: no read only is (or can be) achieved with southbridge registers. TPM is to prevent updates rollback but the secure boot and safe updates are still there
<KaKaRoTo> /WP pin of the flash chip with protect the entire chip, not just a portion of it
<nico_h> no, /WP pin to protected part of the flash chip
<nico_h> usually, /WP only protects the block protection setup of the chip not the whole chip
<nico_h> but... that depends on the chip
<nico_h> KaKaRoTo: the general idea is: 1. have one part RO during runtime (can be achieved with early programming of PCH registers, as avph pointed out). 2. the RO part only runs other (updated) parts if a signature verification worked out
<KaKaRoTo> ok
<KaKaRoTo> I assume the early programming of PCH registers is done by vboot itself already
<avph> not sure but certainly saw stuff like that
<KaKaRoTo> I have this in my TO-READ list, so I'll explore that more later : https://www.coreboot.org/git-docs/Intel/vboot.html
<nico_h> unlikely, as it's mostly only used on chromebooks with the /WP thing

<avph> https://docs.google.com/presentation/d/1h-nsDGlQmYI21dr95nYgLmyCYDgBIpJWSt9b7AqTZaw/pub?start=false&loop=false&delayms=3000 could elucidate some things in chromeos devices, like vboot and the update mechanism

<avph> this patchset https://review.coreboot.org/#/c/coreboot/+/23307/ makes vboot easier to use outside of chromeos

We do not need or want it. Specifically the problem with systems like vboot (and why we went with Heads instead) is that we do not want to require that the BIOS pass a signature check against a key that we control. We want the user to be able to flash with a custom BIOS if they so choose, even if we haven't blessed it with our signature.

Provided we can implement write protection on the BIOS so it can only be reflashed inside Heads, we should have sufficient remote exploit protection and at that point we just want to *detect* tampering but we aren't trying to *prevent* executing code like with vboot, secure boot, etc.

You seem to be trapped in the thinking that signature verification is bad and measuring is good. Please don't see it like that. They both complement each other very well.

Regarding vboot in particular, it is much more than just signature verification (too much to discuss here). Implemented like Google does, it is the most advanced boot integrity solution both in security and owner control. The most precious feature of vboot is a read-only root of trust. It's implemented as a read-only partition of the firmware flash, protected in a way that the device owner can still opt to overwrite it (with physical presence). Earlier systems implemented it as a screw or switch on the mainboard. The current solution is an onboard controller (CR50, IIRC) dedicated to debugging and owner control, AIUI.

This (online-)read-only root of trust also makes it possible to have secure updates on another path than owning the platform: The software/privilege level used for updates doesn't have the ability to change the root of trust. Which makes secure updates less expensive.

If you'd implement vboot, you could decide at any stage to opt-out from signature verification, e.g. when you load the (otherwise protected) OS. And, ofc, you can let the user override the key used for verification or opt-out from any signature verification at all.

AFAICS, your solution with HEADS doesn't have a read-only root of trust. Please correct me if you have one. If I'm not mistaken, any exploitable bug in code that is run before you decide *not* to do an update (and lock the flash chip hence) would allow an attacker to overwrite your root of trust and forge the measuring (and you wouldn't be able anymore "to *detect* tampering"). And with HEADS these are tens or maybe even hundreds of thousands lines of code. Did you audit them well enough?

Oh and btw. how do you intend to detect tampering anyway? Please don't tell me you need a Librem Key. Purism tries to sell the laptops as secure and not secure-with-additional-hardware, right? Or is the Key now part of the laptop shipment? If not, what is your security goal for a humble users without Librem Key?

Earlier systems implemented it as a screw or switch on the mainboard. The current solution is an onboard controller (CR50, IIRC) dedicated to debugging and owner control

There was a post and some discussion about this feature a while ago on HN. The main objections by the author of that post to the use of cr50 were that the cr50's ROM isn't user updateable and can only be updated by the vendor. It was also pointed out that this was also true for prior tpm chips, but cr50's functions are larger in scope since it has access to the spi flash making it more problematic. Is this still true ? It seems like the physical screw system avoids these sorts of issues ?

I'm not sure what vboot is, but if we're talking about Intel Boot Guard, it's my understanding that requires physically blowing fuses within the CPU, that then only allows signed UEFI to actually boot/run.

I agree this isn't a great idea, as some users (myself) would like to be in control of this RoT. Perhaps asking the user, on first boot.

Would you like to Trust Librem's Key (Blow Librem Controlled Hash) or Use your own (Advanced) or something.

I don't believe you can reverse this configuration as it's blown into an WORM (Write-Once Read-Many) area within the CPU