Comment by geor9e
13 days ago
This has been a commonplace feature on SOCs for a decade or two now. The comments seem to be taking this headline as out‑of‑the‑ordinary news, phrased as if Oneplus invented it. Even cheapo devices often use an eFuse as anti-rollback. We do it at my work whenever root exploits are found that let you run unsigned code. If we don't blow an eFuse, then those security updates can just be undone, since any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc. I get the appeal of ROMs/jailbreaking/piracy but it relies on running obsolete exploitable firmware. It's not like they're forcing anyone to install the security patch who doesn't want it. This is normal.
It ain't normal to me. If I bought a phone, I should be able to decide that I want to run different software on it.
Let's say OP takes a very different turn with their software that I am comfortable with - say reporting my usage data to a different country. I should be able to say "fuck that upgrade, I'm going to run the software that was on my phone when I originally bought it"
This change blocks that action, and from my understanding if I try to do it, it bricks my phone.
The whole point of this is so that when someone steals your phone, they can't install an older vulnerable version of the firmware than can be used to set it back to factory settings which makes it far more valuable for resale.
Phone thieves aren't checking which phone brand I have before they knick my phone. Your scenerio is not improved by making Oneplus phones impossible to use once they're stolen.
11 replies →
I'm fine with a total loss of hardware. I'd rather the hardware do what I want. I own it.
It'd be ideal if the phone manufacturer had a way to delegate trust and say "you take the risk, you deal with the consequences" - unlocking the bootloader used to be this. Now we're moving to platforms treating any unlocked device as uniformly untrusted, because of all of the security problems your untrusted device can cause if they allow it inside their trust boundary.
We cant have nice things because bad people abused it :(.
Realistically, we're moving to a model where you'll have to have a locked down iPhone or Android device to act as a trusted device to access anything that needs security (like banking), and then a second device if you want to play.
The really evil part is things that don't need security (like say, reading a website without a log in - just establishing a TLS session) might go away for untrusted devices as well.
7 replies →
> any random enemy with hardware access could plug in a USB cable, flash the older exploitable signed firmware, steal your personal data, install a trojan, etc
A lot of my phones stopped receiving firmware updates long ago, the manufacturer just simply stopped providing them. The only way to safely use them is to install custom firmware that are still address the problems, and this eFuse thing can be used to prevent custom firmware.
This eFuse is part of the plot to prevent user from accessing open source firmware, it's just that. Your "user safety" jargon cannot confuse people anymore, after all the knowledge people (at least the smart few) has learned during the years.
> and this eFuse thing can be used to prevent custom firmware.
This is not what's happening here, though.
On most devices, anti-rollback means "older firmware won't boot" or "you lose secure features." Here it seems to mean "try it and you permanently brick the device," with no warning in the updater and no public statement explaining the change
I don't know about most devices, but for all the ones I've messed with, eFuse anti-rollback always "bricked" them if you rolled back. It was a natural consequence of the firmware essentially being a binary with a USB flashing mode, plus a bootloader to continue into the operating system. If the firmware can't load at all due to failing eFuse check, then you can't load into flashing mode. The same thing would happen if you wrote garbage to the bootloader partition. That's enough for customers and journalists to call it "permanantly bricked". There might be some SOC recovery mode that lets you load a newer bootloader into RAM, but it would need some software tooling from the SOC manufacturer, and at that point few customers will figure it out.
[dead]
This is a phone with an unlockable bootloader (as they should all be). For such a device,
Reasonable: anti-rollback is enforced when the bootloader is locked
Unreasonable: anti-rollback is enforced when the bootloader is unlocked
Unhinged: attempting a download hard-bricks the phone
Sounds like that should be an option in "Developer Options" that defaults to true, and can only be disabled after re-authentication / enterprise IT authorization. I don't see anything lost for the user if it were done this way.
> since any random enemy with hardware access
Once they have hardware access who cares? They either access my data or throw it in a lake. Either way the phone is gone and I'd better have had good a data backup and a level of encryption I'm comfortable with.
This not only makes it impossible to install your own ROMs, but permanently bricks the phone if you try. That is not something my hardware provider will ever have the choice to make.
It's just another nail in the coffin of general computing, one more defeat of what phones could have been, and one more piece of personal control that consumers will be all too happy to give up because of convenience.
[dead]
why don't they work the same way PCs do with UEFI and secure boot? where users decide what certificates go in as trusted root, so they can install their own OS? I'm surprised there hasn't been any anti-trust suits over this by competitor ROM makers.