So, exactly what I said: blocking the ability to ship firmware updates, but not necessarily going out of the way to stop there being any way to do it if it isn't required to block updating it from the OS. They HAVE blocked "out-of-band" updates to accomplish their main goal.
Conversation
Okay so in other words firmware is read only from the perspective of my OS and can't be tampered with unless I pop the back off my phone physically and update by hand. I have the schematics and everything so this is ideal.
I like that.
1
It's not possible to update via OS, not from the perspective of the firmware. No one said the baseband can't receive a firmware update pushed via a cell phone tower, etc. No one said there is verified boot for it. No one said they picked components with security support.
1
1
The baseband is on a separate gemalto daughter card so that is its own black box so I don't think that is in scope here.
That is untrusted by the design of the hardware. Limited access to OS memory .
1
It's not specific to the baseband. It applies to the SoC and the other components. It's also not untrusted in any sense. As a general rule, Linux kernel drivers trust hardware components. You seem to be falling for the false dichotomy of DMA vs. non-DMA being about isolation.
1
Components with DMA can be untrusted, and often are, due to usage of IOMMUs. Components without DMA can be trusted, and often are, due to their role in the design of the device along with the design / implementation of typical drivers trusting the hardware that they support.
1
1
When someone writes a driver for hardware, they're rarely treating that hardware as an attacker. Wi-Fi, much like a cellular baseband, also runs a large RTOS requiring substantial hardening, auditing and regular security updates. You don't get that with these components.
1
If you're simply going to hand an attacker persistent local code execution on a Wi-Fi / Bluetooth / Cellular SoC you're trusting them with direct access to the kernel driver and other code supporting the device from the OS. It's a whole lot more than that too. What about privacy?
2
How are you going to have privacy if you have radios that are broadcasting their vulnerability and can be persistently compromised through known, public exploits? Even without taking control over the OS from there, they have unique hardware identifiers + can track location, etc.
1
This is why I personally will be using the physical switch to leave the radio disabled 99.9% of the time until at least and open/trusted driver exists to assure the memory blast radius is contained.
1
Which radio? All of them? This applies just as much to Wi-Fi and Bluetooth as it does to a cellular radio. They are not substantially different in implementation. Each of these radios is implemented with a substantially large RTOS with a lot of attack surface and complexity.
If the radio isn't designed with great care taken to avoid persistent state + implement full verified boot, then an attacker compromising it is going to trivially gain persistent code execution there. They get unique device identifiers (IMEI, MAC, and assorted others) to track.
1
They can do fine-grained location tracking of the device based on nearby Wi-Fi networks and/or cell phone towers and/or Bluetooth devices. They can also do side channel attacks even without trying to exploit the kernel. They can wait until there's a known driver vulnerability.
1
Show replies
Yep. You are not wrong here either.
Being able to physically swap out the radios for something less terrible is a feature I care about for this exact reason.
Perhaps drivers can be revenged or IOMMU isolated to offer some damage control in the mean time.
1
1
The reality is that hardware and firmware security matters a lot. OS runs on the SoC directly on top of that hardware and firmware. As with software, security updates are important. It's a good thing when hardware is designed so as many security vulnerabilities as possible can be
2
Show replies