Comment by tripdout | Hacker News Reader

Comment by tripdout | Hacker News Reader

Parent Full thread

> When the device powers on, the Primary Boot Loader in the processor's ROM loads and verifies the eXtensible Boot Loader (XBL). XBL reads the current anti-rollback version from the Qfprom fuses and compares it against the firmware's embedded version number. If the firmware version is lower than the fuse value, boot is rejected. When newer firmware successfully boots, the bootloader issues commands through Qualcomm's TrustZone to blow additional fuses, permanently recording the new minimum version

What exactly is it comparing? What is the “firmware embedded version number”? With an unlocked bootloader you can flash boot and super (system, vendor, etc) partitions, but I must be missing something because it seems like this would be bypassable.

It does say

> Custom ROMs package firmware components from the stock firmware they were built against. If a user's device has been updated to a fused firmware version & they flash a custom ROM built against older firmware, the anti-rollback mechanism triggers immediately.

and I know custom ROMs will often say “make sure you flash stock version x.y beforehand” to ensure you’re on the right firmware, but I’m not sure what partitions that actually refers to (and it’s not the same as vendor blobs), or how much work it is to either build a custom ROM against a newer firmware or patch the (hundreds of) vendor blobs.

Firmware (XBL and other non OS components) are versioned with anti rollback values. If the version is less than the version burned into the fuses the firmware is rejected. The “boot” partition is typically the Linux kernel. Android Verified Boot loads and hashes the kernel image and compares it to the expected hash in the vbmeta partition. The signature of the hash of the entire vbmeta metadata is compared to a public key coded into the secondary boot loader (typically abl (fastboot before fastbootd was done in user space to support super partitions))

The abl firmware contains an anti rollback version that is checked with the eFuse version.

The super partition is a bunch of lvm logical partitions on top of a single physical partition. Of these, is the main root filesystem which is mounted read only and protected with dm-verity device mapping. The root hash of this verity rootfs is also stored in the signed vbmeta.

Android Verified Boot also has an anti rollback feature. The vbmeta partition is versioned and the minimum version value is stored cryptographically in a special flash partition called the Replay Protected Memory Block (rpmb). This prevents rollback of boot and super as vbmeta itself cannot be rolled back.

>What exactly is it comparing? What is the “firmware embedded version number”? With an unlocked bootloader you can flash boot and super (system, vendor, etc) partitions, but I must be missing something because it seems like this would be bypassable.

This doesn't make sense unless the secondary boot is signed and there is a version somewhere in signed metadata. Primary boot checks the signature, reads the version of secondary boot and loads it only if the version it's not lower than what write-once memory (fuse) requires.

If you can self-sign or disable signature, then you can do whatever boot you want, as long as it's metadata satisfies the version.

Reply on news.ycombinator.com