The primary threat model for verified boot is defending against a remote attacker trying to persist on the device, not physical security. Anti-tampering is a secondary and less important threat model for verified boot. Chromebooks don't really bother even trying to do that part.
Conversation
If the owner could re-flash the entire device, it wouldn't be possible for a remote attacker to persist in the first place...?
1
You flash device by interacting with firmware on the device and there are a whole bunch of components which have firmware: SoC firmware including firmware for GPU, media encode/decode, image processing, crypto engine, TEE and much more, touchscreen, battery, USB controller, etc.
2
I guess we're now entering the realm of "what if", but it would be nice to have a ROM that can be used to clean flash it.
(And open source firmware for everything)
1
Open source firmware for everything implies making a new SoC based on open RISC-V core designs and creating a GPU and all the other components like the memory controller, USB controller, battery, touchscreen, TEE, secure element, etc. as part of that too.
2
Open source firmware doesn't imply not having verified boot and rollback protection.
Trusty OS and OpenTitan are open source so there's a starting point for making TEE and secure element with the same base that current and future Pixels will be using for the foreseeable future.
1
Verified boot is okay, so long as the owner makes the decisions and controls the chain of trust.
Rollback protection, however, is pretty incompatible with open source. There is no "backward" when an attacker can just add the exploit "feature" to a new version.
1
Rollback protection is an inherent part of verified boot because any non-trivial software is going to have vulnerabilities. It's feasible to make a bootrom that's highly secure and doesn't have vulnerabilities found but it's really not feasible to avoid it in all that firmware.
2
The OS itself certainly needs rollback protection for verified boot to work because there are endless Linux kernel vulnerabilities, etc. Really important for the TEE and secure element to work in general too. OS could just downgrade them to vulnerable versions otherwise.
1
Also, with the owner signing, where will an attacker get the vulnerable versions to roll back to?
This threat is 99% because it's the manufacturer signing rather than the owner.
1
1
What's enforcing the root of trust that's set by the owner? On a Pixel, it's this firmware boot chain which loads the root of trust from the secure element. In order for the OS to have verified boot, the firmware boot chain and secure element need verified boot before it.
Snapdragon/Exynos/Tensor bootrom essentially reads a public key fingerprint that was irreversibly burned into the SoC and uses it to verify the early firmware. Rollback protection is done with fuses too. Each stage chains along trust to next until the stage passing to user RoT.
1
In theory, you could get an SoC without a root of trust flashed into it and flash your own to the fuses. In practice, you can't, and you'd still be locking yourself into using specific keys, but your own keys, or keys of firmware/OS you chose, but you couldn't change your mind.