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.
According to OP this does not disable bootloader unlocking in itself. It makes the up-versioned devices incompatible with all previous custom ROMs, but it should be possible to develop new ROM releases that are fully compatible with current eFuse states and don't blow the eFuse themselves.
I understand that there is a nuance somewhere, but that's about it.
Can you explain it in simpler terms such that an idiot like me can understand? Like what would an alternative OS have to do to be compatible with the "current eFuse states"?
People need to re-sign their releases and include the newer version of bootloader, more or less.
Yes, though noting that since the antirollback is apparently implemented by the bootloader itself on this Qualcomm SoC, this will blow the fuse on devices where the new version is installed, so the unofficial EDL-mode tools that the community seems to be most concerned about will still be unavailable, and users will still be unable to downgrade from the newer to older custom ROM builds.
EDL itself is a huge hack anyway, so who knows. The underlying issue is that the OS suppliers are forced to bundle what is effectively the equivalent of a BIOS (low-level firmware) with their image (because of the underlying assumption that this is an embedded system where there are no third-party OS suppliers), and the "BIOS" update has to be made a one-way street when the older firmware has vulnerabilities. Newer EDL tools ought to become available but they might not have the exact same capabilities as the older ones, though they'll most likely be usable for basic recovery.
Not being able to downgrade and using the debug tools was the exact point of doing this thing, as far as I understand.
I wonder, is there currently unpublished 0day on the SoC and they're forcing use of the latest firmware to ensure they're not vulnerable once the details become public? That would be a reason for suddenly introducing this without explanation.
So that’s how in an event of war US adversaries will be relieved of their devices
> The anti-rollback mechanism uses Qfprom (Qualcomm Fuse Programmable Read-Only Memory), a region on Qualcomm processors containing one-time programmable electronic fuses.
What a nice thoughtful people to build such a feature.
That’s why you sanction the hell out of Chinese Loongson or Russian Baikal pity of CPU — harder to disable than programmatically “blowing a fuse”.
This kind of thing is generally used to disallow downgrading the bootloader once there is a bug in chain of trust handling of the bootloader. Otherwise once broken is forever broken. It makes sense from the trusted computing perspective to have this. It's not even new, it was still there on p2k motorollas 25 years ago.
You may not want trusted computing and root/jailbreak everything as a consumer, but building one is not inherently evil.
Trusted computing means trusted by the vendor and content providers, not trusted by the user. In that sense I consider it very evil.
If the user doesn't trust an operating system, why would they use it. The operating system can steal sensitive information. Trusted computing is trusted by the user to the extent that they use the device. For example if they don't trust it, they may avoid logging in to their bank on it.
> If the user doesn't trust an operating system, why would they use it.
Because in the case of smartphones, there is realistically no other option.
> For example if they don't trust it, they may avoid logging in to their bank on it.
Except when the bank trusts the system that I don't (smartphone with Google Services or equivalent Apple junk installed), and doesn't trust the system that I do (desktop computer or degoogled smartphone), which is a very common scenario.
>to protect against platform abuse, but mostly not to protect corporate interests
What do you mean by this? On both Android and iOS app developers can have a backend that checks the status of app attestation.
Yes, I do believe from the bottom of my heart the users trust the operating systems they use. Apple and Google have done a great job at security and privacy which is why it seems like users don't care. It's like complaining why you have a system administrator if the servers are never down. When things are run well the average person seems ignorant of the problems.
Pre-TC mobile/embedded security was catastrophic:
Persistent bootkits trivial to install
No verified boot chain
Firmware implants survived OS reinstalls
No hardware-backed key storage
Encryption keys extractable via JTAG/flash dump
Arguably yes. By preventing entire classes of attack real users are never exposed to certain risks in the first place. If it were possible it would be abused at some rate (even if that rate were low).
It's not that trusted computing is inherently bad. I actually think it's a very good thing. The problem is that the manufacturer maintains control of the keys when they sell you a device.
Imagine selling someone a house that had smart locks but not turning over control of the locks to the new "owner". And every time the "owner" wants to add a new guest to the lock you insist on "reviewing" the guest before agreeing to add him. You insist that this is important for "security" because otherwise the "owner" might throw a party or invite a drug dealer over or something else you don't approve of. But don't worry, you are protecting the "owner" from malicious third parties hiding in plain sight. You run thorough background checks on all applicants after all!
Yes. See attacks like Pegasus.
A discussion you don't see nearly enough of is that there is a fundamental tradeoff with hardware security features — every feature that you can use to secure your device can also be used by an adversary to keep control once they compromise you.
In this case, the "adversary" evaluates to the manufacturer, and "once they compromise you" evaluates to "already". This is the case with most smartphones and similar devices that treats the user as a guest, rather than the owner.
See also:
https://github.com/zenfyrdev/bootloader-unlock-wall-of-shame
Not only can, but inevitably is. Security folks - especially in mobile - are commonly useful idiots for introducing measures which are practically immediately coopted to take away users ability to control their device and modify it to serve them better. Every single time.
We just had the Google side loading article here.
[dead]
Fair enough, but so does your front door. Either thing is not smart enough to judge the legitimacy of ownership transitions.
Yeah, not disagreeing with you. It's just that, every time we have this discussion, we see comments like GP's rebutted by comments like yours, and vice versa.
All I'm saying is that we have to acknowledge that both are true. And, if both are true, we need to have a serious conversation about who gets to choose the core used in our front door locks.
I’d like to think I’m buying the device, not a seat to use the device, at least if I do not want to use their software.
You can't have that with phones. You are always at the mercy of the hardware supplier and their trusted boot chain that starts with the actual phone processor (the one running GSM stuff, not user interface stuff). That one is always locked down and decides to boot you fancy android stuff.
The fact that it's locked down and remotely killable is a feature that people pay for and regulators enforce from their side too.
At the very best, the supplier plays nice and allows you to run your own applications, remove whatever crap they preinstalled and change to font face. If you are really lucky, you can choose to run practically useless linux distribution instead of practically useful linux distribution with their blessing. Blessing is a transient thing that can be revoked any time.
Nor the Mediatek platforms as far as I know (very familiar with the MT65xx and MT67xx series; not sure about anything newer or older, except MT62xx which also boots --- from NOR flash --- the AP first.)
There are some open firmware, or partially open firmware projects, but they're more proof-of-concepts and not popular/widely-used. The problem is the FCC or corresponding local organization requires cell phones get regulatory approval, and open firmware (where just anybody could just download the source and modify a couple of numbers to violate regulations) doesn't jive with that.
https://hackaday.com/2022/07/12/open-firmware-for-pinephone-...
>Obviously we don't have that. But what stops an open firmware (or even open hardware) GSM modem being built?
The same thing that stops you from living on a sea platform as a sovereign citizen or paying for your groceries with bitcoin. Technically you can, but practically you don't.
If you want to sell it commercially, you can opensource all you want, but the debug interface and bootloader integrity would have to be closed shut for production batch.
At best, you can do what the other comment refers to -- instead of using the baseband as a source of root of trust, make it work like wifi modules. This of course comes at a cost of having a separate SoC. Early motorola smartphones (EZX series) did that -- Linux part talked to the gsm part literally over usb. It came with all kinds of fun, including sound being khmm... complicated. I don't remember whether they shared the RAM zo. You don't want to share you RAM with a funny blob without reading fine print about who sets up the mappings, right?
Figuring out all of that costs money and money have to come from somewhere, which means you also have to resist the pressure to not become part of the problem. And then the product that comes out is 5 years too late for the spec and 1.5 times too expensive for the vague promise of "trust me bro, I will only blow the e-fuse to fix actual CVEs".
>The GSM processor is often a separate chip
Is it? I remember MotoMing of EZX years to be actually separate and maybe the latest failed attempts at linux phone had one, but I'm under impression the most common way to do it is a SoC where one core is doing baseband and the other(s) are doing linux and they also share the physical RAM that is part of the same SoC. I don't follow the happenings close enough to say it's 100% of all phones and people call me out saying mediatek is totally حلال in this department. It's not like I'm going to touch anything with mtk ever to check.
Of course you can have that.
The governments can ban this feature and ban companies from selling devices with that.
> It's not even new, it was still there on p2k motorollas 25 years ago.
I’m sure CIA was not founded after covid :-)
Uhh…Wut?
Let me remind you the gist of the parent comment:
> So that’s how in an event of war US adversaries will be relieved of their devices
OTP memory is a key building block of any secure system and likely on any device you already have.
Any kind of device-unique key is likely rooted in OTP (via a seed or PUF activation).
The root of all certificate chains is likely hashed in fuses to prevent swapping out cert chains with a flash programmer.
It's commonly used to anti rollback as well - the biggest news here is that they didn't have this already.
If there's some horrible security bug found in an old version of their software, they have no way to stop an attacker from loading up the broken firmware to exploit your device? That is not aligned with modern best practices for security.
> they have no way to stop an attacker from loading up the broken firmware to exploit your device
You mean the attacker having a physical access to the device plugging in some USB or UART, or the hacker that downgraded the firmware so it can use the exploit in older version to downgrade the firmware to version with the exploit?
Sure. Or the supply chain attacker (who is perhaps a state-level actor if you want to think really spicy thoughts) selling you a device on Amazon you think is secure, that they messed with when it passed through their hands on its way to you.
Modern devices try to prevent this by cryptographically entangling the firmware on the flash to the chip - e.x. encrypting it with a device-unique key from a PUF. So if you replace the chip, it won't be able to decrypt the firmware on flash or boot.
The evil of the type of attack here is that the firmware with an exploit would be properly signed, so the firmware update systems on the chip would install it (and encrypt it with the PUF-based key) unless you have anti-rollback.
Of course, with a skilled enough attacker, anything is possible.
If this would be the reason, downgrading would wipe the device not brick it permanently.
> You mean the attacker having a physical access to the device plugging in some USB or UART
... which describes US border controls or police in general. Once "law enforcement" becomes part of one's threat model, a lot of trade-offs suddenly have the entire balance changed.
Example of evil maid attack. On laptops prevented automatically by secure boot or manually by encryption and checking fingerprints, not by bricking whole device.
eFuses have been a thing forever on almost all MCUs/processors, and aren't some inherently "evil" technology - mostly they're used in manufacturing when you might have the same microcontroller/firmware on separate types of boards. I'm working on a board right now which is either an audio input or an output (depending on which components are fitted) and one or the other eFuse is burned to set which one it is, so subsequent firmware releases won't accidentally set a GPIO as an output rather than an input and potentially damage the device.
Isn't this normally done with a GPIO bootstrap?
It depends. Usually there are enough "knobs" that adding that many balls to the package would be crazy expensive at volume.
Most SoCs of even moderate complexity have lots of redundancy built in for yield management (e.x. anything with RAM expects some % of the RAM cells to be dead on any given chip), and uses fuses to keep track of that. If you had to have a strap per RAM block, it would not scale.
There's so many ways to do this, but a simpler method is to hide a small logic block (somewhere in the 10 billion transistors of your CPU) that detects a specific, long sequence of bits and invokes the kill switch.
Baikal definitely has anti-rollback, and Loongson should have it too. That's a common feature.
As of efuses, they are present essentially anywhere. In any SoC and microcontroller. They are usually used to store secrets (keys) and for chip configuration.
The linked wiki article written in a way that the reader might assume that OnePlus did something wrong, unique, anti-consumer, or something along the lines. Quite the contrary: OnePlus issued updated official firmware with burned the anti-rollback bit to prevent older vulnerable official firmware from being installed. Either new bootloader-level vulnerability has been found, or some kind of bootloader-level secret has leaked from OnePlus, with which the attacker can gain access to the smartphone's data it should not have. By this update, OnePlus secured data of the smartphone owners again.
You still can unlock the bootloader and install custom firmware (with bumped anti-rollback version in the firmware metadata I guess, that would require newer custom firmware or a recompilation/header modification for the older). Your device with the custom firmware installed won't receive the official firmware update to begin with, so it could not be bricked.
This has been going on for a long, long time. Motorola used to make Android phones that would burn an efuse in the SoC if it thought it was being rooted or jailbroken, bricking the phone.
>That’s why you sanction the hell out of Chinese Loongson or Russian Baikal
I assume that's also why China is investing so heavily into open source risc-v
This is absurdly paranoid with absolutely zero evidence. For embedded and mobile threat models where physical access or bootloader unlock is possible, eFuses are effectively mandatory for robust downgrade prevention
Agreed that robust downgrade prevention is necessary. However it's not paranoid at all and the problem isn't limited to eFuses. A network connected device that the vendor ultimately controls is a device that can be remotely disabled at the vendor's whim. It's like a hardware backdoor except it's out in the open and much more capable.
[dead]
This goes beyond the 'right to repair' to simply the right of ownership. These remote updates prove again and again that even though you paid for something you don't actually own it.
It's basically the same for our automobiles, just try to disable the "phone home" parts connected to the fin on the roof. Do we really own out cars if we can't stop the manufacturer from telling us we need to change our oil through email?
Buy a Volvo. Then you can pop out the SIM card to disable the car's cellular communication. (On mine, located behind the mirror.)
When you really need it, like to download maps into the satnav, you can connect it to your home WiFi, or tether via Bluetooth.
Hahah, I just traded in 2023 (unrelated brand) for 2012 model since it was less of a computer. Computer systems in the newer car kept having faults that caused sporadic electrical issues workshops couldn’t fix. I just want my car to be a car and nothing else.
1997... and that's my last car. No way I'm going to be driving around in a piece of spyware.
Until they switch to eSIM...
... and get a Check Engine light+fault code for the built-in emergency SOS feature, thereby making it unable to pass vehicle inspection until you fix the antennae
Chinese-owned Volvo?
OnePlus and other Chinese brands were modders-friendly until they suddenly weren't, I wouldn't rely on your car not getting more hostile at a certain point
There was a video by MKBHD where he said that every new phone manufacturer starts off being the hero and doing something different and consumer/user friendly before with growth and competition they evolve into just another mass market phone manufacturer. Realistically this is because they wouldn't be able to survive without being able to make and sell mass market phones. This has already happened to OnePlus back half a decade ago when they merged with Oppo, and it's arguably happened with ASUS as well when they cancelled the small form factor phone a couple years ago.
Chinese-owned Volvo?
Shhh. Nobody tell him where his phone, computer, and vast majority of everything else in his house was made.
A phone without SIM can still be used to call emergency services (911/999/0118999 8819991197253). The situation we're discussing though is an attack by an extremely-APT. You really think not having the SIM card is going to do anything? If the cell phone hardware is powered up, it's available. All the APT has to do is have put their code into the baseband at some point, maybe at the Volvo factory when the car was programmed, and get the cooperation of a cell-phone tower, or use a Stingray to report where the car is when in range.
it's actually 0118 999 881 999 119 7253, you missed the beginning
it's from IT Crowd https://www.youtube.com/watch?v=HWc3WY3fuZU
Indeed.
My ownership is proved by my receipt from the store I bought it from.
This vandalization at scale is a CFAA violation. I'd also argue it is a fraudulent sale since not all rights were transferred at sale, and misrepresented a sale instead of an indefinite rental.
And its likely a RICO act, since the C levels and BOD likely knew and/or ordered it.
And damn near everything's wire fraud.
But if anybody does manage to take them to court and win, what would we see? A $10 voucher for the next Oneplus phone? Like we'd buy another.
As far as legal arguments go, I imagine their first counter would be that you agreed to the update, so it's on you.
A forced update or continual loop of "yes" or "later" is not consent. The fact that there is no "No" option shows that.
Fabricated or fake consent, or worse, forced automated updates, indicates that the company is the owner and exerting ownership-level control. Thus the sale was fraudulently conducted as a sale but is really an indefinite rental.
> If I buy a used vehicle for example, I have exactly zero relationship with the manufacturer. I never agree to anything at all with them. I turn the car on and it goes. They do not have any authorization to touch anything.
Generally speaking and most of the time, yes; however, there are a few caveats. The following uses common law – to narrow the scope of the discussion down.
As a matter of property, the second-hand purchaser owns the chattel. The manufacturer has no general residual right(s) to «touch» the car merely because it made it. Common law sets a high bar against unauthorised interference.
The manufacturer still owes duties to foreseeable users – a law-imposed duty relationship in tort (and often statute) concerning safety, defects, warnings, and misrepresentations. This is a unidirectional relationship – from the manufacturer to the car owner and covers product safety, recalls, negligence (on the manufacturer's behalf) and alike – irrespective of whether it was a first- or second-hand purchase.
One caveat is that if the purchased second-hand car has the residual warranty period left, and the second-hand buyer desires that the warranty be transferred to them, a time-limited, owner-to-manufacturer relationship will exist. The buyer, of course, has no obligation to accept the warranty transfer, and they may choose to forgo the remaining warranty.
The second caveat is that manufacturers have tried (successfully or not – depends on the jurisdiction) to assert that the buyer (first- or second-hand) owns the hardware (the rust bucket), and users (the owners) receive a licence to use the software – and not infrequently with strings attached (conditions, restrictions, updates and account terms).
Under common law, however, even if a software licence exists, the manufacturer does not automatically get a free-standing right to remotely alter the vehicle whenever they wish. Any such right has to come from a valid contractual arrangement, a statutory power, or the consent, privity still works and requires a consent – all of which weakens the manufacturer's legal standing.
Lastly, depending on the jurisdication, the manufacturer can even be sued for installing an OTA update on the basis of the car being a computer on wheels, and the OTA update being an event of unauthorised access to the computer and its data, which is oftenimes a criminal offence. This hinges on the fact that the second-hand buyer has not entered into a consentual relationship with the manufacturer after the purchase.
A bit of a lengthy write-up but legal stuff is always a fuster cluck and a rabit hole of nitpicking and nuances.
Their defense would probably be like: "you clicked Yes on the EULA form."
When a remote update can irreversibly change hardware state, ownership becomes conditional
You either die a hero, or live long enough to see yourself become the villain
I think the writing has been on the wall since they started their Nord line.
Do you mean because the previous "flagship killer" company now needed a "flagship killer" sub-brand, since they could no longer be categorised as such?
Exactly, why did they end up in a situation where they are making killers of their "main" phones ?
OnePlus still leads on custom ROM support though, e.g. no special codes or waiting times needed for unlocking the bootloader, it all works out of the box with standard commands.
Google Pixel would like to have a word. Though they regressed since they stopped shipping device trees in AOSP.
What was the issue with the Nord line?
yeah, i'd like to know that too. i have a oneplus nord running /e/OS and i am quite happy with it. in fact it's probably the best phone i had so far performance wise (i got it refurbished at a very good price which may have something to do with that though)
OnePlus is a textbook case of that quote
Unfortunately similar things will be mandated by EU law through cyber resiliance act (CRA) in order to ensure tamper free boot of any kind of device sold in the EU from Dec 2027.
Basically breaking any kind of FOSS or repairability, creating dead HW bricks if the vendor ceases to maintain or exist.
What's worrying isn't the CRA itself, but that companies may use it as cover to lock things down more than necessary
Shouldn't the EU then escrow keys?
What do OnePlus gain from this? Can someone explain me what are the advantages of OnePlus doing all this? A failed update resulting in motherboard replacement? More money, more shareholders are happy?
I still sometimes ponder if oneplus green line fiasco is a failed hardware fuse type thing that got accidentally triggered during software update. (Insert I can't prove meme here).
My understanding is there was a bug that let you wipe and re-enable a phone that had been disabled due to theft. This prevents a downgrade attack. It's in OnePlus's interest to make their phones less appealing for theft, or, in their interest to comply with requirements to be disableable from carriers, Google, etc.
Carriers can check a registry of stolen phone IMEIs and block them from their networks.
right, but the stolen phones get sold in other countries where the carriers don't care if the phone was stolen but care that someone is spending money on their service.
And we cant own our phones due to that?
There is a surprising number of carriers in the world that don't care if you're using a stolen phone.
Not surprisingly, stolen phones tend to end up in those locations.
I have never seen this happen.
I have however experienced that a ISP will write to you because you have a faulty modem (some Huawei device) and asks you to not use it anymore.
All offers seem to be from the US.
I the lines between IMEI banning or blacklisting and the modern unlocking techniques they use have been blurred a little bit and so some carriers and some manufacturers don't really want to do or spend time doing the IMEI stuff and would prefer to just handle it all via their own unlocking and locking mechanisms.
With vulnerable FW, you can change IMEIs. Hence this kind of rollback prevention updates.
Make perfect sense, Thanks kind stranger. Hope it is the reason and not some corporate greed. It on me, lately my thoughts are defaulted towards corporates sabotaging consumers. I need to work on it.
The effects on custom os community is causing me worried ( I am still rocking my oneplus 7t with crdroid and oneplus used to most geek friendly) Now I am wondering if there are other ways they could achieved the same without blowing a fuse or be more transparent about this.
I don't think so. Blowing a fuse is just how the "no downgrades" policy for firmware is implemented. No different for other vendors actually, though the software usually warns you prior to installing an update that can't be manually rolled back.
Are you quite certain?
Google pushed a non-downgradable final update to the Pixel 6a.
I was able to install Graphene on such a device. Lineage was advertised and completely incompatible, but some hinted it would work.
> It on me, lately my thoughts are defaulted towards corporates sabotaging consumers. I need to work on it.
You absolutely do not, this is an extremely healthy starting position for evaluating a corporations behavior. Any benefit you receive is incidental, if they made more money by worsening your experience they would.
As I understand it, this is a similar thing on Samsung handhelds:
> It's in OnePlus's interest to make their phones less appealing for theft,
I don't believe for a second that this benefits phone owners in any way. A thief is not going to sit there and do research on your phone model before he steals it. He's going to steal whatever he can and then figure out what to do with it.
Which is why I mentioned that carriers or Google might have that as a requirement for partnering with them. iPhones are rarely stolen these days because there's no resale market for them (to the detriment of third party repairs). It behooves large market players, like Google or carriers, to create the same perception for Android phones.
Thieves don't do that research to specific models. Manufacturers don't like it if their competitors' models are easy to hawk on grey markets because that means their phones get stolen, too.
It actually seems to work pretty well for iPhones.
Thieves these days seem to really be struggling to even use them for parts, since these are also largely Apple DRMed, and are often resorting to threatening the previous owner to remove the activation lock remotely.
Of course theft often isn't preceded by a diligent cost-benefit analysis, but once there's a critical mass of unusable – even for parts – stolen phones, I believe it can make a difference.
Yes thieves do, research on which phones to steal. Just not online more in personal talking with their network of lawbreakers. In short a thief is going to have a fence, and that person is going to know all about what phones can and cannot be resold.
> My understanding is there was a bug that let you wipe and re-enable a phone that had been disabled due to theft. This prevents a downgrade attack.
This makes sense and much less dystopia than some of the other commenters are suggesting.
That's even more dystopian.
Their low-level bootloader code contains a vulnerability that allows an attacker with physical access to boot an OS of their choice.
Android's normal bootloader unlock procedure allows for doing so, but ensures that the data partition (or the encryption keys therefore) are wiped so that a border guard at the airport can't just Cellebrite the phone open.
Without downgrade protection, the low-level recovery protocol built into Qualcomm chips would permit the attacker to load an old, vulnerable version of the software, which has been properly signed and everything, and still exploit it. By preventing downgrades through eFuses, this avenue of attack can be prevented.
This does not actually prevent running custom ROMs, necessarily. This does prevent older custom ROMs. Custom ROMs developed with the new bootloader/firmware/etc should still boot fine.
This is why the linked article states:
> The community recommendation is that users who have updated should not flash any custom ROM until developers explicitly announce support for fused devices with the new firmware base.
Once ROM developers update their ROMs, the custom ROM situation should be fine again.
That makes sense, but how would an attacker flash an older version of the firmware in the first place? Don't you need developer options and unlocking + debugging enabled?
Qualcomm phones come with a special mode (https://en.wikipedia.org/wiki/Qualcomm_EDL_mode) that allows devices to get unbricked even after you break the normal user-updatable "bootloader" on flash completely.
This feature doesn't allow unlocking the bootloader (as in, execute a custom ROM), it's designed to install factory-signed code. However, using it to "restore" an old, vulnerable factory code would obviously cause issues.
Open the case and pogo pin on a flash programmer directly to the pins of the flash chip.
Sophisticated actors (think state-level actors like a border agent who insists on taking your phone to a back room for "inspection" while you wait at customs) can and will develop specialized tooling to help them do this very quickly.
thank you for this, I have a follow up question: Now an attacker can not install an old, vulnerable version. But couldn't they just install a new, vulnerable version? Is there something that enforces encryption key deletion in one case and not the other?
AFAIK the signature mechanism hasn't been defeated, so the attacker can only load software signed by the factory keys.
Which includes old, vulnerable versions and all patched, newer versions. By burning in the minimum version, the old code now refuses to boot before it can be exploited.
This is standard practice for low-level bootloader attacks against things like consoles and some other phone brands.
> What do OnePlus gain from this? Can someone explain me what are the advantages of OnePlus doing all this?
They don't want the hardware to be under your control. In the mind of tech executives, selling hardware does not make enough money, the user must stay captive to the stock OS where "software as a service" can be sold, and data about the user can be extracted.
A bit overdramatic, isn't it? Custom ROMs designed for the new firmware revisions still work fine. Only older ROMs with potentially vulnerable bootloader code cause bricking risks.
Give ROM developers a few weeks and you can boot your favourite custom ROMs again.
Not really dramatic IMO. Basically mirrors everything we have seen in other industries like gaming consoles, etc. that have destroyed ownership over time in favor of "service models" instead.
And now governments are starting to take advantage of that loss of control by demanding surveillance tech like chatcontrol and other backdoors.
Note that Google also forces this indirectly via their "certification" - if the device doesn't have unremovable AVB (requires qualcomm secure boot fuse to be blown) then it's not even allowed to say the device runs Android.. if you see "Android™" then it means secure boot is set up and you don't have the keys, you can't set up your own, so you don't really own the SoC you paid for..
I don't think it's accurate.
Specifically GrapheneOS on Pixels signs their releases with their own keys. And with the rollback protection without blowing out any fuses.
I was talking about different keys and different fuses. I know about "avb_custom_key" (provisioned by GrapheneOS), but all this AVB is handled by abl/trustzone and I can't modify those because those need to be signed with keys that I don't own.
I know that all these restrictions might make sense for the average user who wants a secure phone.. but I want an insecure-but-fully-hackable one.
> In the mind of tech executives
To be fair, they are right: the vast majority of users don't give a damn. Unfortunately I do.
Sure if you want to compete against Google or Samsung. Maybe that is the plan that one plus has. My understanding was that they were going after a different Market of phone users that might want a little bit more otherwise why not just go with one of the other people that will screw you just as hard for less.
It is the same concept on an iPhone, you have 7 days to downgrade, then it is permanently impossible. Not for technical reasons, but because of an arbitrary lock (achieved through signature).
OnePlus just chose the hardware way, versus Apple the signature way
Whether for OnePlus or Apple, there should definitively be a way to let users sign and run the operating system of their choice, like any other software.
(still hating this iOS 26, and the fact that even after losing all my data and downgrading back iOS 18 it refused to re-sync my Apple Watch until iOS 26 was installed again, shitty company policy)
> Not for technical reasons, but because of an arbitrary lock (achieved through signature).
There is a good reason to prevent downgrades -- older versions have CVEs and some are actually exploitable.
and ? this should prevent you from deciding the level of risk or even installing forks of that OS (that can also write fixes, even without source-code by patching binaries) ?
I'm not sure if this is the case anymore, but many unbranded/generic Androids used to be completely unlocked by default (especially Mediatek SoCs) and nearly unbrickable, and that's what let the modding scene flourish. I believe they had efuses too, but software never used them.
It's Google's fault. I want to buy a smartphone without AVB at all. With no "secure boot" fuse blown (yes I DO know that this is not the same fuse) and ideally I'd want to provision my own keys.
But vendors wouldn't be able to say the device runs "Android" as it's trademarked. AVB is therefore mandatory and in order for AVB to be enforced, you can't really control the device - unlocking the bootloader gives you only partial control, you can't flash your own "abl" to remove AVB entirely.
But I don't want AVB and I can't buy such device for money.. this isn't free market, this is Google monopoly..
The closest thing you can get is probably the Pixel, ironically. You can provision your own keys, enroll it into AVB, and re-lock the bootloader. From the phone hardware's perspective there is no difference between your key and Google's. No fuse is ever blown.
That's not really true, there will be a warning shown that "the phone is loading a different operating system" - I've seen that when installing GrapheneOS on my pixel.
But it's not just about that, it's about the fact that I can't flash my own "abl" or the software running in the TrustZone there at all as I don't control the actual signing keys (not custom_avb_key) and I'm not "trusted" by my own device.. There were fuses blown as evident by examining abl with its fastboot commands - many refuse to work saying I can't use it on a "production device". Plus many of those low-level partitions are closed source proprietary blobs..
Yes yes - I DO understand that for most people this warning is something positive, otherwise you could buy a phone with modified software without realizing it and these modifications could make it impossible to restore the original firmware.
Ah, I forgot about the warning. Are the blown fuses you're talking about related to to your unlocking though? Or did they just remove the debug functions. I guess it reduces the attack surface somewhat.
I do agree it's far from ideal though. But there are so many, much worse offenders that uses these fuses to actually remove features, and others that do not allow installing a different OS at all. The limited effort should probably be spent on getting rid of those first.
I'm not sure I'd agree with your last conclusion, we as consumers can choose what to buy, so for me the situation where there's one brand that produces open devices (with competing specs, not like pinephone..) where I could install postmarketos/ubuntu touch without any parts of android would be better than there being many brands producing smartphones allowing only basic unlocking and without open firmware.
Of course there are bigger problems in the ecosystem, like Play Integrity which actively attempt to punish me for buying open hardware. Unfortunately that's the consequence of putting "trusted" applications where they IMO don't belong - there are smartcards with e-ink displays and these could be used for things like banking confirmations, providing the same security but without invading my personal computing devices. But thanks to Android and iOS, banks/governments went for the anti-user option.
> 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.
What exactly is the threat model here of preventing Joe Nobody Famous or Important Poweruser from rooting the hardware they bought and paid for?
If someone has physical access to your phone, you have a lot more to worry about than mere root exploits. And given those who root their devices are far out of the profile of ordinary users, so a specially targeted hack like this is pointless as compared to the regular kind of exploits in apps that can target a wider base.
Blind speculation: I wonder if this is in some way related to DRM getting broken at a firmware level, leading to a choice being made between "users complain that they can't watch netflix" and "users complain that they can't install custom ROMs".
It was because a method was discovered to bypass the lockout of stolen devices.
In other words the same old boogeyman they always use to justify this crap.
From what I understand this does not prevent use of custom ROMs, it just means ROMs built before it was done will not work anymore. I assume they can re-package old versions to work with the new configuration, I am not entirely sure though. There are discussions elsewhere in this thread with more informed people.
Oh damn I missed that detail.
OnePlus has pretty much become irrelevant since Carl Pei left the company. Its more or less just a rebranded Oppo nowadays. I'm not an android user anymore but I'm rooting for his new(ish) Nothing company. Hopefully it carries the torch for the old OnePlus feel.
As an early OnePlus user (1, 3, 5, 7, 13) i find myself unimpressed with what Nothing is proposing, feels more like a design exercise than a flagship killer
They consistently have allowed bootloader unlocking without extra fuss and have had good LineageOS support. That is their main appeal, IMO. Nothing phones had no LineageOS support until recently (spacewar is now supported, unsure about other models), and it's not clear if there's enough of a community/following to keep putting LineageOS on them. I do not want any phone where I'm stuck with the stock ROM.
Nothing phones also allow seamless bootloader unlocking, just like OnePlus. There's been some rumors that OnePlus might be about to exit the market altogether, if so Nothing will probably expand into their niche and beyond their current approach based on "unique" design.
This is true, but only half the equation. Nothing Phone 1 took ages to get LineageOS support and the already-supported OnePlus 8T had similar specs. Though if OnePlus pisses everyone off, maybe Nothing will take their place and get more LOS maintainers, in which case I'd be fine switching to their devices.
I've been with OnePlus since the beginning, and am not at all impressed by the Nothing. Primary missing feature which I've come to depend on, off screen gestures, is missing. And the device just comes across as foreign in general; makes me think of the iPhone, which is not something I want to think of.
Yup - and worse than that too.
In the last week or two it's been rumoured that Oppo are pulling the plug on OnePlus, and are going to wind up the brand entirely. (Although it may cling on in certain markets, like India).
If this becomes the norm, it effectively ends the idea that you own the hardware you paid for
I look forward to the 1hr+ rant from Louis Rossmann.
He has already made the video on this, but it is only 3:23: https://youtu.be/3AiRB5mvEsk?si=XapAHhHRJtssDI4F
isnt this just like... vandalism? nothing could give them the right to do this, they're damaging others property indescriminately.
Does anyone know if it has been confirmed that this only applies to the "ColorOS" branded firmware versions? Because I currently have an update to OxygenOS 16.0.3.501 pending on my OnePlus 15, which is presumably built from the same codebase.
Edit: It seems that this does apply to OxygenOS too: https://xdaforums.com/t/critical-warning-coloros-16-0-3-501-...
Damn, I just saw that update yesterday on my phone and did not update it for no reason. Turned off auto-update right now until I figure out what to do.
Is this for just one or several OnePlus models?
If so, is this 'fuse' per-planned in the hardware? My understanding is cell phones take 12 to 24 months from design to market. so, initial deployment of the model where this OS can trigger the 'fuse' less one year is how far back the company decided to be ready to do this?
Lots of CPUs that have secure enclaves have a section of memory that can be written to only once. It's generally used for cryptographic keys, serials, etcetera. It's also frequently used like this.
Fuses are there on all phones since 25+ years ago, on the real phone CPU side. With trusted boot and shit. Otherwise you could change IMEI left and right and it's a big no-no. What you interact with runs on the secondary CPU -- the fancy user interface with shiny buttons, but that firmware only starts if the main one lets it.
Otherwise you could change IMEI left and right and it's a big no-no.
You can still change the IMEI on many phones if you know how to.
This is in the Qualcomm SOC chip, so it's not something that has to be designed into the phone per se.
This does not surprise me from the company that accidentally deleted the widevine L1 certificate on my phone (that never had any third party OS) during an update and could not restore it, nor would it replace the motherboard (for which it claimed it was the only possible fix).
That's insane. If the CPU has enough fuses (which according to the wiki it does) why the h*ck can't they just make it impossible to reflash the >= minimum previously installed version of the OS after preventing the downgrade? Why the hard brick?
So much ignorance in this thread. There's nothing new here. All manufacturers worth their salt have this feature.
This is ultimately about making the device resistant to downgrade attacks. This is what discourages thieves from stealing your phone.
I've been dismayed by how fast the "we should own our hardware" crowd has so quickly radicalized into "all security features are evil", and "no security features should exist for anyone".
Not just "there should be some phone brands that cater to me", but "all phone brands, including the most mainstream, should cater to me, because everyone on earth cares more about 'owning their hardware' than evil maid attack prevention, Cellebrite government surveillance, theft deterrence, accessing their family photos if they forget their password, revocable code-signing with malware checks so they don't get RATs spying on their webcam, etc, and if they don't care about 'owning their hardware' more than that, they are wrong".
It is objectively extremist and fanatical.
"No security features should exist for anyone" is itself fanatically hyperbolic narrative. The primary reason this event has elicited such a reaction is because OnePlus has historically been perceived as one of the brands specifically catering to people that wanted ultimate sovereignty over their devices.
As time goes on, the options available for those that require such sovereignty seem to be thinning to such an extent that [at least absent significant disposable wealth] the remaining options will appear to necessitate adopting lifestyle changes comparable to high-cost religious practices and social withdrawal, and likely without the legal protections afforded those protected classes. Given the "big tech's" general hostility to user agency and contempt for values that don't consent to being subservient to its influence peddling, intense emotional reaction to loss of already diminished traditional allies seem like something that would reasonably viewed compassionately, rather than with hostility.
I’ve posted about this on HN before; I think that there’s a dangerous second-order enshittification going on where people are so jaded by a few bad corporate actions that they believe that everyone is out to get them and hardware is evil. The most disappointing thing to me is that this has led to a complete demolition of curiosity; rather than learning that OTP is an ancient and essential concept in hardware, the brain-enshittification has led to “I see hardware anti-*, I click It’s Evil” with absolutely no thought or research applied.
Given how the opposition has radicalized into "you should own nothing and be happy", it's not surprising.
None of the situations you mentioned are realistic or even worth thinking about for the vast majority of the population. They're just an excuse to put even more control into the manufacturer's hands.
How is graphene considered the most secure phone os but you can still flash on new firmware?
I don't care if they can downgrade the device, just that I boot into a secure verified environment, and my data is protected.
I also think thieves will just grab your phone regardless, they can still sell the phone for parts, or just sell it anyway as a scam etc.
The attack is simple: the attacker downgrades the phone to a version of firmware that has a vulnerability. The attacker then uses the vulnerability to get at your data. Your data is PIN-protected? The attacker uses the vulnerability to disable the PIN lockout and tries all of them.
There's over a 10x difference in fence price between a locked and unlocked phone. That's a significant incentive/deterrent.
Don't pixels have a security chip that is supposed to make that infeasible?
It has some increasing timer for auth, and if you try and factory reset it - it destroys all the data?
As I said its less important that the thief can boot a new os, the security of my data is more important. How is that compromised?
It feels like a thief is just going to opportunistically grab a phone from you rather than analyse what device it is.
Glad I didn't give these people any of my hard earned dollars.
Nintendo has been doing this for ages.
Why? What advantage do they get from this? I'm assuming it's not a good one but I'm struggling to see what it is at all.
They patched a low-level vulnerability in their boot process. Their phones' debug features would allow attackers to load an old, unpatched version of their (signed) software and exploit it if they didn't do some kind of downgrade prevention.
Using eFuses is a popular way of implementing downgrade prevention, but also for permanently disabling debug flags/interfaces in production hardware.
Some vendors (AMD) also use eFuses to permanently bond a CPU to a specific motherboard (think EPYC chips for certain enterprise vendors).
They can kill custom roms and force the latest vendor firmware. If they push a shitty update that slows down the phone or something, users have no choice other than buying a new device.
The article suggests custom roms can just be updated to be 'newer' than this.
At the moment they're 'older' and would class as a rollback, which this fuse prevents.
Does intentionally physically damaging a device fall foul of any laws that a software restriction otherwise wouldn't?
This is industry standard. Flashing old updates that are insecure to bypass security is a legitimate attack vector that needs to be defended against. Ideally it would still be possible up recover from such a scenario by flashing the latest update.
Standard?? The standard is for the upgrade to be refused or not boot until you flash a newer one, not to brick the phone permanently. It's not an "ideally" thing for the manufacturer to not intentionally brick your device you bought and paid for.
>and you may damage your device permanently
https://service.oneplus.com/us/search/search-detail?id=op588
They make it clear that this feature is unsupported and it's possible to mess things up. The reason why it's an ideal and not an expectation is that flashing alternate operating systems is done at one's own risk and is unsupported. They have already told the users that they bear no responsibility for what may go wrong if they flash the wrong thing on that device. Flashing incompatible operating systems to the device requires people to be careful and proper care to ensure compatibility before going through with flashing was not done.
What's being attacked in this particular case?
The phone. It's the same attacks that secure boot tries to protect against. The issue is that these old, vulnerable versions have a valid signature allowing them to be installed.
How likely is it that such software-activated fuse-based kill switches are built into iPhones? Any insights?
So this article isn't about a kill switch, just blocking downgrades and custom ROMs.
But to answer your question: we know iPhones have a foolproof kill switch, it's a feature. Just mark your device as lost in Find My and it'll be locked until someone can provide your login details. Assuming it requires logging in to your Apple account (which it does, AFAIK; I don't think logging in to a local account is enough), this is the same as a remote kill switch; Apple could simply make a device enter this locked-down state and then tweak their server systems to deny logins.
I'd say for commercial hardware it is a near certainty even if you won't ever know until it is much too late.
Realize that many of these manufacturers sell their hardware in and employ companies in highly policed societies. Just the fact that they are allowed to continue to operate implies that they are playing ball and may well have to perform a couple of favors. And that's assuming they are fully aware of what they are shipping, which may not be always the case.
I don't think it is a bad model at all to consider any cell phone to be compromised in multiple ways even though you don't have hard proof.
Apple has been doing that since forever and will remotely kill switch devices so they need to be destroyed instead of reused: https://fighttorepair.substack.com/p/activation-locks-send-w...
Millions of fully working apple devices are destroyed because of that even - Apple won't unlock them even with proof of ownership.
It's there on all phones since forever lol. Apple can ship an update that adds "update without asking for confirmation" tomorrow and then ship another one that shows nothing but a middle finger on boot and you would not be able to do anything, including downgrading back.
The M-series CPUs found in iPads (which cannot boot custom payloads) are the same as the M-series CPUs found in Macbooks (which can boot custom payloads) - just with different fuses pre-burnt during manufacturing.
Pre-prod (etc.) devices will also have different fuses burnt.
iPhones already cannot be downgraded, they can only install OS versions signed by apple during the install time. (search SHSH blobs) They also can't run unsigned IPA files (apps). Not sure if they have a physical fuse, but it's not much different.
The significant difference is that if it were placed into DFU mode and connected to an appropriate device that had access to appropriately signed things, it could be "unbricked" without replacing the mainboard.
true, but I believe these bricked oneplus devices can also be revived from 9008 (EDL) if they can find the qualcomm firehorse loader file.
100%, if you steal a phone from the Apple store they just remote brick it.
How hard is it to fix a fuse with a microscope and a steady hand?
Very hard. FIB is the only known way to do this but even then, that's the type of thing where you start with a pile of SoCs and expect to maybe get lucky with one in a hundred. A FIB machine is also millions of dollars.
You'll need at least an electron microscope... but defeating MCU readout protection using a FIB is actually a thing:
https://www.eag.com/services/engineering/fib-circuit-edit-de...
Costs are what you'd expect for something of this nature.
I thought they were the one okay manufacturer. Guess not.
So OnePlus is no better than the rest of the pack.
How does an eFuse even work?
Its high time we start challenging these sorts of actions as the "vandalization and sabotage at scale" that these attacks really are. I dont see how these aren't a direct violation of the CFAA, over millions of customer-owned hardware.
They are no different than some shit ransomware, except there is no demand for money. However, there is a demonstrable proof of degradation and destruction of property in all these choices.
Frankly, criminal AND civil penalties should be levied. Criminally, the C levels and boars of directors should all be in scope as to encouraging/allowing/requiring this behavior. RICO act as well, since this smells like a criminal conspiracy. Let them spend time in prison for mass destruction of property.
Civally, start dissolving assets until the people are made whole with unbroken (and un-destroyed) hardware.
The next shitty silly-con valley company thinks about running this scam of 'customer-bought but forever company owned', will think long and hard about the choices of their network and cloud.
> no demand for money
There is when the device becomes hard bricked and triggers an unnecessary need for a new one.
im sure that is not going to improve their sales numbers
It's my first time hearing about this "eFuse" functionality in Qualcomm CPUs. Are there non-dystopian uses for this as a manufacturer?
Samsung uses this for their Knox security feature. The fuse gets broken in initial bootloader unlock, and all features related to Knox (Samsung Pay, Secure Folder, etc) gets disabled permanently even after reverting to stock firmware.
eFuses are in most CPUs, often used for things like disabling hardware debug interfaces in production devices - and rollback prevention.
Almost every modern SoC has efuse memory. For example, this is used for yield management - the SoC will have extra blocks of RAM and expect some % to be dead. At manufacturing time they will blow fuses to say which RAM cells tested bad.
I use them in an esp32 to write a random password to each of my products, so when I sell them they can each have their own secure default wifi password while all using the same firmware.
What advantage do you see from using eFuses and not some other way to store the password?
This is the only way I could come up with that would allow an end user to do a full factory reset, and end up back in a known good secure state afterwards.
Storing it in the firmware would mean every user has the same key. Storing it in eeprom means a factory reset will clear it. This allows me to ship hardware with the default key on a sticker on the side, and let's a non technical user reset it back to that if they need to.
It gives you a 256bit block to work with - https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...
But couldn't you also just set aside a bit of the EEPROM your factory reset skips, and accomplish the same thing?
There are not. The entire premise of eFuses are that after you buy something, the manufacturer can still make changes that you can't ever undo.
Oneplus went shit since the 6. Pretty sad, they used to be a great brand...
This is absolutely cracked. I've been with OnePlus since the One, also getting the 2, 6 and now I have the 12. Stuck with them all these years because I really respected their - original - take on device freedom. I really should've seen the writing on the wall given how much pain it is to update it in the first place, as I have the NA version which only officially allows carrier updates, and I don't live in NA (and even if I did I'd still not be tied to a carrier).
Now I have to consider my device dead re updates, because if I haven't already gotten the killing update I'd rather avoid it. First thing I did was unlock the bootloader, and I intend to root/flash it at some point. Will be finding another brand whenever I'm ready to upgrade again.
This wasn't their only pain point. [1] Just get off OnePlus, you'll be happier.
Fascinating. I've had a OnePlus 6 from 2018 until 2023 (all on stock software) and I've not had or noticed any issues like that.
You probably haven't had any apps that need to stay open a long time, or perhaps they have a way to relaunch themselves as a workaround. I've definitely seen this and it's incredibly frustrating to see processes killed when they need to stay running and are not doing anything wrong.
What are good alternatives that aren't Pixel?
For now, Pixels. I'm waiting to see what non-Pixel phone will be supported by GrapheneOS next, but this may take a while.
Yeah I'm surprised that they announced it but not the vendor name. I'm sure Google with their infinite resources already know which vendor it is. So who are they hiding it from?
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.
> It reduces the expected value of stealing a phone, which reduces the demand for stolen phones.
It's not at all obvious that this is what happens. To begin with, do you regard the average phone thief as someone who even knows what expected value is?
They want drugs so they steal phones until they get enough money to buy drugs. If half the phones can't be resold then they need to steal twice as many phones to get enough money to buy drugs; does that make phone thefts go down or up?
On top of that, the premise is ridiculous. You don't need to lock the boot loader or prevent people from installing third party software to prevent stolen phones from being used. Just establish a registry for the IMEI of stolen phones so that carriers can consult the registry and refuse to provide service to stolen phones.
It's entirely unrelated to whether or not you can install a custom ROM and is merely being used as an excuse because "prevent theft somehow" sounds vaguely like a legitimate reason when the actual reason of "prevent competition" does not.
I find it hard to believe that Oneplus is spending engineering and business recourses, upsetting a portion of their own userbase, and creating more e-waste because they want to reduce the global demand for stolen phones. They only have like 3% of the total market, they can't realistically move that needle.
I don't understand what business incentives they would have to make "reduce global demand for stolen phones" a goal they want to invest in.
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.
> That's fundamentally incompatible with my worldview and I explicitly think it should be legislated out of existence.
The model that makes sense to me personally is that private companies should be legislated to be absolutely clear about what they are selling you. If a company wants to make a locked down device, that should be their right. If you don't want to buy it, that's your absolute right too.
As a consumer, you should be given the information you need to make the choices that are aligned with your values.
If a company says "I'm selling you a device you can root", and people buy the device because it has that advertised, they should be on the hook to uphold that promise. The nasty thing on this thread is the potential rug pull by Oneplus, especially as they have kind of marketed themselves as the alternative to companies that lock their devices down.
How is that supposed to fix anything if I don't trust the hypervisor?
It's funny, GP framed it as "work" vs "play" but for me it's "untrusted software that spies on me that I'm forced to use" vs "software stack that I mostly trust (except the firmware) but BigCorp doesn't approve of".
> 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.