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.
Conversation
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.
2
3
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
fixed via firmware updates. I don't think you would take a huge software project seriously that has no way to ship security updates to users. The hardware complexity is immense, for the SoC (CPU, GPU and everything else on it) and also the other components. SoC is highly trusted.
1
OS sits on top of the SoC. It is limited by the security of the SoC. The mitigations for the software are limited by what the SoC supports. When you render something with the GPU, you're depending on the GPU firmware/hardware design and IOMMU isolation (if any...) as a backup.
I don't know what the SoC supports as far as memory isolating the PCI bus but that is worth exploring as it will be critical to being able to distrust the radios.
I do appreciate these thoughts. My goal of distrusting the radios has not changed but as you state, it is hard.