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.
Conversation
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.
1
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
Replying to
I gave you plenty of information which you ignore and don't look into further, and you then go ahead with continuing to make the same clearly false and refuted claims over and over again. I don't see much point in talking to someone not being honest or acting in good faith.
1
Replying to
I am really sorry you see it that way.
So far your most specific stated issue with the desire to isolate the radios from the OS is that the drivers for these modems are badly designed.
I would love to learn specifics as I don't see a lot of concerns online.
2
Replying to
So, as before, ignoring most of what I am saying and just cherry-picking bits of it and misrepresenting the topic along with what I have said. I really don't see the point in any of these threads.
2
We currently target devices where Bluetooth, Wi-Fi and cellular is implemented in dedicated sandboxes on a chip that is itself isolated from the OS. They have all the basic mitigations deployed for them and a fair bit of external security research looking into it.
1
It's largely the norm to have isolated radios. Wi-Fi is often a chip connected via PCIe that's not properly isolated and has full memory access, even beyond what the kernel can directly access itself, but it's pretty rare to have a *cellular* radio like that on an actual phone.
1
Wi-Fi has typically not been included on the smartphone SoC until recently and therefore it was up to OEMs to go out of the way to implement isolation for it and of course they don't actually tend to do that. Most OEMs don't really have hardware security teams doing that stuff.
As one example, any phone that has Broadcom Wi-Fi will generally have it connected via PCIe with no attempt to isolate it. Broadcom doesn't appear to care much about privacy/security and doesn't offer Wi-Fi anonymity (MAC rand via OS doesn't provide it) or hardening/sandboxing.
1
I'm sure they share blame for the fact that pretty much any OEM shipping their Wi-Fi hardware ends up with it having full memory access, but it also reflects on how very few OEMs are going to do any substantial security work even just to integrate things in a secure way.