5 ms·

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 One

• palijer 9mo ago
  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.
  • jnwatson 9mo ago
    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.
    • QuiEgo 9mo ago
      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.
      • charcircuit 9mo ago
        >and then a second device if you want to play. With virtualization this could be done with the same device. The play VM can be properly isolated from the secure one.
        • fc417fc802 9mo ago
          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".
          • charcircuit 9mo ago
            Then yes you will need a another device. Same if you don't trust the processor.
            • fc417fc802 9mo ago
              > Same if you don't trust the processor. Well I don't entirely, but in that case there's even less of a choice and also (it seems to me) less risk. The OEM software stack on the phone is expected to phone home. On the other hand there is a strong expectation that a CPU or southbridge or whatever other chip will not do that on its own. Not only would it be much more technically complex to pull off, it should also be easy to confirm once suspected by going around and auditing other identical hardware. As you progress down the stack from userspace to OS to firmware to hardware there is progressively less opportunity to interact directly with the network in a non-surreptitious manner, more expectation of isolation, and it becomes increasingly difficult to hide something after the fact. On the extreme end a hardware backdoor is permanently built into the chip as a sort of physical artifact. It's literally impossible to cover it up after the fact. That's incredibly high risk for the manufacturer. The above is why the Intel ME and AMD PSP solutions are so nefarious. They normalize the expectation that the hardware vendor maintains unauditable, network capable, remotely patchable black box software that sits at the bottom of the stack at the root of trust. It's literally something out of a dystopian sci-fi flick.
    • palijer 9mo ago
      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.
      • creato 9mo ago
        It reduces the expected value of stealing a phone, which reduces the demand for stolen phones.
        • palijer 9mo ago
          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.
          • charcircuit 9mo ago
            This is a security feature from Qualcomm. So there is little of their own time spent on this.
            • ValdikSS 9mo ago
              And it is a SoC requirement for Android certification.
        • AnthonyMouse 9mo ago
          > 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.
    • echelon 9mo ago
      I'm fine with a total loss of hardware. I'd rather the hardware do what I want. I own it.
• g947o 9mo ago
  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.
• troyvit 9mo ago
  > 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.
  • Gippersnark 9mo ago
    [dead]
• nirui 9mo ago
  > 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.
  • zozbot234 9mo ago
    > and this eFuse thing can be used to prevent custom firmware. This is not what's happening here, though.
• veunes 9mo ago
  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
  • geor9e 9mo ago
    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.
  • Gippersnark 9mo ago
    [dead]
• notepad0x90 9mo ago
  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.
• Zak 9mo ago
  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