OfflinePuffin Could an open source bootloader use in this way?
This issue isn't whether or not a bootloader is open-source. But if the OS, meaning malware running inside the OS, can tamper with the bootloader, it's not a basis for trust.
OfflinePuffin Or does there need to be tight integration with hardware.
An effective verified-boot infrastructure requires cooperation between hardware and software. In theory this can be done on any kind of machine (phone, desktop), but in practice so far the effective implementations are mostly on phones.
Two recent examples:
- For a while, the bootloader in Fairphone phones used a key for which both halves (public and "private") were public (oops), so in practice anybody could sign any malware-ridden kernel and the Fairphone bootloader would declare it to be genuine (source). This is not a common mistake for phone vendors to make.
- Meanwhile, in the desktop PC world, 200+ devices made that same mistake (source).
My sense is that verified boot works better on good phones (e.g., Pixels, iPhones) than on Apple "desktop" machines, which in turn are way ahead of regular PCs.
Based on a quick glance, it looks to me as if the Vanilla AvB ABroot infrastructure is designed to protect against innocent mishaps during upgrades, not to protect against malware. That doesn't mean it's a bad thing! But if it doesn't protect against malware persistence then it doesn't protect against malware persistence, and then it isn't the same thing as what happens when you boot GrapheneOS on a Pixel, even if the name of the technology is similar.
Oh, also, see LogoFAIL.