AOSP uses the timestamp of the Android security patch level as the default rollback index. For example, it's currently 1656979200 for 2022-07-05.
The vbmeta image has hashes of all the core OS images and hashes of dm-verity roots for the high-level OS images to bootstrap those.
Conversation
It's also possible to have chained vbmeta images, where a public key is included instead of a hash. Each chained vbmeta image has their own rollback index stored in a secure element rollback index slot. For example, Pixel 6 has chained boot and system vbmeta to support GKIs/GSIs.
1
Most of the core OS components are included in the OS as an APK, which means they're a signed package able to be updated out-of-band. A subset of those are APEX modules, which are a signed APK containing chained vbmeta verified filesystem image, used for things beyond just apps.
1
Important to note is Android's verified boot verifies every block read from storage. Core OS images are read once and verified via their hash. dm-verity provides continuous verification each time blocks are read for the high level images and APEX modules.
1
The reason they made fs-verity is so that regular APKs for apps can be continuously verified rather than just APEX modules shipping verified filesystems inside. Apps are signed / verified even without this, but it allows quick continuously verification, not verify once on boot.
1
You can chain trust to a user installed app using hardware-based attestation. Provides signed response chaining up to attestation root including verified boot state (green, yellow), signing key (useful for yellow), various versions, etc. and also your app id + key fingerprint.
1
Officially supports pinning your own hardware backed attestation signing keys now too, which is a feature we (GrapheneOS) proposed for use in our Auditor app (attestation.app/about). Shipped on Pixel 6 but it has a bug we reported they need to fix for it to be fully usable.
1
1
1
fs-verity initially extended continuous verification to out-of-band privileged system apps. Continuous verification is now available for all apps via v4 signing scheme. It's just to make the signing more hardened, like it is for the base OS, avoiding trusting SSD firmware, etc.
1
All of this can surely be done in a similar way for a desktop Linux distribution. The main blocker is that the secure boot, attestation and hardware keystore implementations available on most desktops/laptops are incredibly crippled compared to this. It'd also be a lot of work.
1
Can still have out-of-band package updates for the base OS. Need secure element support for storing arbitrary rollback indexes. It's a whole lot easier to do it right with verified base OS images so you can get your package manager, etc. from there.
1
Other main blocker would be that most software on desktop Linux cannot run in a proper, truly contained standard app sandbox beyond distributing each app as something that runs in app-specific VM instances. Flatpak / Snap are still pretty far from actually being enough.
What we built with the existing secure boot approach is a component that contributes towards a meaningful security policy in the long run. I agree that in itself it's not usefully there yet, and it needs to be for the userland security work to actually work well.
2
Also not stated above is that all of that that supports A/B updates for firmware / OS images. Failed boot after update rolls back everything automatically. It's even able to mount data and then roll it back via f2fs checkpoint disable. Wish I had a server distro to use with this.
1