5 ms·

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-On

• rwmj 9mo ago
  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.
• Muromec 9mo ago
  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.
  • piskov 9mo ago
    > It's not even new, it was still there on p2k motorollas 25 years ago. I’m sure CIA was not founded after covid :-)
    • obnauticus 9mo ago
      Uhh…Wut?
      • piskov 9mo ago
        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
  • pdpi 9mo ago
    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.
    • Muromec 9mo ago
      Fair enough, but so does your front door. Either thing is not smart enough to judge the legitimacy of ownership transitions.
      • pdpi 9mo ago
        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.
    • izacus 9mo ago
      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.
    • digiown 9mo ago
      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 https://github.com/zenfyrdev/bootloader-unlock-wall-of-shame
    • ihsw 9mo ago
      [dead]
  • wasmainiac 9mo ago
    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.
    • Muromec 9mo ago
      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.
      • the8472 9mo ago
        Not true on the pinephone, the modem is a peripheral module, so the boot chain does not start with it.
        • userbinator 9mo ago
          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.)
      • RobotToaster 9mo ago
        > You can't have that with phones. Why not? Obviously we don't have that. But what stops an open firmware (or even open hardware) GSM modem being built?
        • fragmede 9mo ago
  • wolvoleo 9mo ago
    Trusted computing means trusted by the vendor and content providers, not trusted by the user. In that sense I consider it very evil.
    • charcircuit 9mo ago
      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.
      • mzajc 9mo ago
        > 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.
      • bigyabai 9mo ago
        Do you actually, bottom-of-your-heart believe that ordinary consumers think like this? They use TikTok and WhatsApp and Facebook and the Wal-Mart coupon app as a product of deep consideration on the web of trust they're building? Users don't have a choice, and they don't care. Bitlocker is cracked by the feds, iOS and Android devices can get unlocked or hacked with commercially-available grey-market exploits. Push Notifications are bugged, apparently. Your logic hinges on an idyllic philosophy that doesn't even exist in security focused communities.
        • charcircuit 9mo ago
          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.
• deleted 9mo ago
  [deleted]
• nippoo 9mo ago
  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.
  • direwolf20 9mo ago
    Isn't this normally done with a GPIO bootstrap?
    • QuiEgo 9mo ago
      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.
• RobotToaster 9mo ago
  >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
• QuiEgo 9mo ago
  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.
  • mrsssnake 9mo ago
    > 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?
    • QuiEgo 9mo ago
      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.
      • c22 9mo ago
        The state level supply chain attacker can just replace the entire chip, or any other part of the product. No amount of technical wizardry can prevent this.
        • QuiEgo 9mo ago
          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.
• neonsunset 9mo ago
  [dead]
• KennyBlanken 9mo ago
  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.
• UltraSane 9mo ago
  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
  • fc417fc802 9mo ago
    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.
• ValdikSS 9mo ago
  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.