I hear a lot about how all cell phone radios have DMA to the rest of the phone… Why must this be? If it is a concern, then would it not be easy to have the radio’s hardware and software jailed or containerized? Are there any phones that do not have this DMA / shared memory issue?
Thanks.
USB does not have direct memory access therefore isn’t prone to DMA attack. L5 and PinePhone are both using USB bus to connect foreign CPU (broadband modem).
3 Likes
‘It “must” be’ because it’s cheaper, simpler, and higher performance. Cheaper because you don’t need a second set of memory chips for the modem (and possibly not a second memory controller). Simpler because you don’t need to negotiate communication protocols or deal with latency. Higher performance because the modem->speaker and mic->modem route can both be zero-copy, with the modem writing (or reading) the data to (or from) a shared buffer.
If the radio’s software were open, you might be able to jail it, but it’s not, so you can’t. A hardware jail is an interesting idea though. If you could trust the memory controller, you could possibly allocate some small portion of the memory bank as “shared” between the host and modem. In practice, this would be where the modem would track its state, and provide those shared buffers, and the host CPU would not use it for anything other than those shared buffers. The hard part if verifying that the memory controller really will only give the modem the thin slice it’s supposed to.
If you go with a sufficiently old phone (2008ish?), you can avoid the shared memory issue. If you go with a phone with a slotted modem, you can also avoid it (raspberry pi phone, comodore64 phone, pinephone, librem 5, anyone know any others?) Of course, depending on what bus they use, there might be other issues instead. Of the phone or phone kits listed, I think the C64 has the best separation between modem and host, but it’s also the most expensive (about $1k Australian), and bulkiest (about the size of an old C64). On the other hand, it has an incredible battery life, lots of office and game software available (all open source, by virtue of being written in basic), and solar charging.
4 Likes
If you could trust the memory controller, you could possibly allocate some small portion of the memory bank as “shared” between the host and modem
The IOMMU in modern SoCs could help with ‘jailing’ DMA devices as well as their drivers. But it’s pretty hard to avoid loopholes at that level. So I think using USB radios for Librem phones was a good choice.
Right, if I were to go the integrated hardware route, I’d want the isolation at the hardware level. A NUMA-capable memory controller, with the modem memory a distinct zone, and the modem not physically connected to the primary zone. A major reason for going the USB route is m.2 mounted USB cards already exist, for use in vending machines and the like, so that reduces the development cost, at the expense of latency and size.
The C64 phone has a neat approach for mitigating performance penalties. It doesn’t pass the call audio to the host, except as a tap, instead it has a hardware sound mixer. So the call audio gets routed to and from the mic directly. Since you don’t want the modem potentially listening to the mic when not in a call, it uses a software controlled (by the host system) hardware sound mixer, with like 8 channels. So the speaker and mic get disconnected when not in use. This has the neat side effect that you can reboot the phone while in a phone call and not drop the call (and in fact, continue your conversation).
now THAT is NEAT indeed !
I think that is clever especially keeping a call running over reboot, but also, buses such as USB2+ don’t have any problem with handling surround sound at full throughput, so a phone call shouldn’t be a problem 
Maybe it does for really high bandwidth packet radio (5G etc) though.
Not a matter of throughput, it’s a matter of latency and battery use. Sending the audio over a USB bus means encoding the audio as USB messages, sending them over the wire, decoding them on the other side and writing them into memory, then pointing the hardware ADC at that spot in memory to generate the analog wave for the speaker. That takes CPU time, which drains the battery and introduces latency. That latency is likely to be small (10ms or less), but only by having the CPU work harder. This is compared to shared memory, which is zero copy, and only involves sending the downstream application an updated pointer to the current buffer (or in the case of the C64 phone, just generating the analog signal on the modem directly).
In the case of the C64 phone, this was kinda necessary, as the FPGA C64 runs at something like 60mhz, so the audio delay would be noticeable to do it in software.
1 Like