It's not even just the kernel driver exposed from the OS as attack service. It's the software stack using the kernel driver to talk to the radio too. It's all the kernel infrastructure exposed by that kernel driver as attack surface. In general, people don't write drivers with
Conversation
the hardware explicitly treated as an adversary. You actually do get a lot from using an SoC platform with a huge amount of resources put into hardening components, isolating them, hardening drivers and also a whole lot of security researchers targeting it and improving it.
1
Replying to
Well as you yourself state, security researchers can never -assure- it is not malicious when the stack is so large and complex, so I would rather have a clean firewall between the radios and the OS for starters.
Keep making the zone that needs to be safe smaller.
2
At this point we have a long history of sophisticated attack demonstrates that give us good reason as a community to start advocating for drivers, especially for complex stacks like radios, to treat every hardware component as malicious.
1
I want a device where the radios in it are no more trusted than the ISP modem in the corner.
I want to assume it is backdoored and malicious at all times, so when it is, I am covered.
1
Replying to
A radio that's compromised is a tracking device that you're carrying around with you and that includes Bluetooth, Wi-Fi, etc. Not to mention that things like Wi-Fi pose a greater threat than you probably realize. They can actually gain info on the environment beyond location.
1
Replying to
Job #1 is assume they are malicious so they can't get into the OS.
Job #2 is making sure they themselves are not compromised
Physical switches to turn them off when not needed is short term damage control until they can be assured trusted.
1
Job #1 is much easier than Job #2 IMO.
You imply you trust radio hardware will be totally secure as long as all firmware updates are blindly applied as they come out.
I don't trust that. I want them quarantined for damage control.
2
Replying to
No, I don't, and I specifically brought up that it's pretty bad to be switching away from a modem with substantial auditing, mitigations, sandboxing, research directed at it, a driver which is designed not to trust it and has a lot of attention from researchers for that, etc.
1
Replying to
Well I don't want to give up my ability to switch modems at any time as the landscape changes.
There are 2 modems you can use in the Librem5: puri.sm/faq/supported-
cdc-acm/cdc-eth are in-kernel at least and it would be worth hardening them more to protect many devices.
1
Replying to
Look, go ahead and get hardware that's insecure and unfixable from day one. Give up on trying to peddle scams and misinformation to me. You really don't know the subject matter, and it's not interesting to have you try to explain things to me that you don't know about.
Replying to
I was just sharing my current understanding in hopes you might give specific knowledge you might have about the hardware in question because that would be super interesting.
You claim the drivers for these modems are not secure. I am only trying to probe you to elaborate.
2
The only information I can find on the listed modems atm is that they use the in kernel cdc drivers. Maybe that is not true!
I don't have one to confirm yet.