This is a guest post by Ricardo "arcee" Cerqueira who takes things apart for sport, on a quest to understand how they work. He currently works on Android devices at Cyanogen.
As people started receiving their Nexus 6Ps, some began freaking out over a new message that comes up on the screen when booting into fastboot mode: “QFUSE: ENABLED,” with wild speculative theories coming up regarding what it does and doesn’t do, what kind of limitations it’s imposing, and wondering if and how it can be “disabled.” So... what’s this qFuse thing, anyway?
Think of an eFuse as the mind’s eye representation of a bit that only flips one way, or something that can only be done once on a piece of writeable flash. Once you flip those bits by writing something into them, there’s no going back: they’ll stay written with that value, forever, and from that point onwards, that chunk of flash essentially becomes ROM (in the original sense of the acronym: read-only memory).
On a smartphone, eFuses (which, depending on who’s marketing the feature, will have different names — the current hot thing is Qualcomm’s “qFuse”) will store bits of data that the vendor doesn’t want anyone screwing around with.
Which brings me to bootloaders: the bootloader on a device powers up some parts of the device, configures them, and then enforces first-line security in protecting your data. That starts at “refusing to run an unauthorized operating system on a locked device,” goes through, “Don’t let unauthorized tools dump the contents of the flash,” and ends up at, “try to protect device viability by not allowing you to destroy the bootloader chain by accident.”
Having that in mind, here’s another factoid on most chipsets, and particularly Qualcomm’s, like the Nexus 6P: besides the main high-level operating system (Android, or the Android recovery) running on the main chip, there’s a lower-level OS running on a companion DSP, and that OS runs apps. DRM negotiation, fingerprint validation, and even video encoding/decoding run as specialized apps on that core, protected by a few security layers. One such layer is making sure that only trusted apps run in that environment, and that trust is achieved by having them signed with a crypto key, and ensuring that only apps signed with that key are allowed to run (you don’t want your fingerprints intercepted, do you? And the content studios definitely don’t want DRM keys tampered with :) ).
The bootloader itself can also be considered one such trusted app: it’s either signed with the correct key, or the device will refuse to run it. If your phone ran any compatible bootloader, it could, for example, get a bootloader that did unlocking without destroying the data (there go your passwords, and those pictures of your wife). Or just a bootloader that skipped boot checks entirely, and allowed any bootable image to get booted or flashed, regardless of lock state.
The key that signs these NON-HLOS (yup, that’s what it stands for: Non-high-level Operating system) apps is not the same key that validates the bootable images. Those are validated by the bootloader alone, and the bootloader can (and does) validate however it sees fit: it’s a micro-OS of its own, and autonomous enough for it. The key that validates the bootables (boot.img, recovery.img) usually lives on the bootloader itself, or somewhere it can read. And if you unlock your bootloader, that’s the key it will no longer check for.
So where does the public key that validates the bootloader itself (and the NON-HLOS apps) live? You guessed it: an eFuse. If that particular fuse is empty, the device will run any low-level firmware (and for people working on the device, especially people working on DSP apps or the bootloader itself, it’s extremely handy to have such a device on hand). But for everyone else, including the people actually working on Android (at or outside Google), that fuse stores the public key that validates firmware. You can’t accidentally break your bootloader, you can’t intercept DRM keys, you can’t sneakily get /data out of a user’s phone or dump it whole, which are all “bad things.” But you can still run your own variant of Android, recovery, or an entirely different high-level OS. And that’s a great thing.
Can the “QFUSE: ENABLED” message on the 6P bootloader refer to another fuse? Yes, but I doubt it: Occam’s Razor and all that. Having worked with multiple physically identical devices myself, it is very useful for people flashing things to be able to visually distinguish which devices will accept a new experimental (and unsigned) bootloader. I’ve bricked multiple devices on account of that :).
TL;DR: The qFuse doesn't affect unlocking the bootloader or any of the phone's features, and it isn't affected by unlocking the bootloader. It's a Nexus after all. Unlock at will!
Image credit: linkmedia360