9 ms·
I'd rather say the issue is NOT that basebands need hardening (ok they do need it), but that we should stop putting things there. The article mentions parsing
by phh 3y ago
I'd rather say the issue is NOT that basebands need hardening (ok they do need it), but that we should stop putting things there.
The article mentions parsing XML, doing DNS, IMS, TCP and IP stacks. As far as I know, all of those are down for one single purpose which is VoLTE (And VoWifi, and other related features which all go under the umbrella of "IMS"). On top of that, they also need to do IPSec (should be pretty safe) and SIP (gosh wait too much string handling). The remote Pixel security flaw few months ago was in that VoLTE stack.
This stack should NOT be in an embedded closed source un-auditable system. It should be in a "dumb" sandboxed opensource app in a sandboxed language.
This is exactly what I'm doing: https://github.com/phhusson/ims https://github.com/phhusson/ims This is a FLOSS VoLTE + VoWifi[1] implementation for Android written in kotlin with no native code [2].
I'm not recommending it for anyone (I managed to make my first outgoing call with it yesterday), it has real issues (you do want baseband cooperation on various parts, like QoS or roaming to 3G, which I'm choosing to ignore), but I think software IMS is the way of the future.
In addition to security, this allows for a lot of de-obsoleting:
- It helps *a lot* for custom Android ROMs, and compatibility with annoying carriers
- I can integrate top-notch audio codecs (EVS) without breaking a sweat, and deployed for everyone in a jiffy (heck I don't even to reboot user's smartphone's to apply the change, I can just deploy it over Play Store)
- I can integrate modern voice improvements
- I can enable VoWifi on 3G smartphones (Granted, I'm not sure that's extremely useful)
- I can enable features that didn't exist when that smartphone model got released like Cross-Sim VoWifi (you have your french main SIM, you're in the US with a local eSIM, you can do VoWifi of the french SIM over the local eSIM to have cheap 4G voice calls)
I see some movement in AOSP source code that make me think Google will release an opensource IMS within two years, so I'm hopeful my work will be able to go to the trash.
[1] I'm kinda cheating for the wifi part, because it's provided by AOSP, I barely lifted the little finger to enable it.
[2] Okay, I added rnnoise for the sake of having a denoising, but it's fixed-size-data-in fixed-size-data-out, so I feel safe there.
PS: I know that my knowledge of 3GPP is pretty thin, so if knowledgeable people want to tell me which parts will still need to remain in modem, I'm curious.
PS2: I'm putting this just in case: For GNU/Linux smartphones (or desktops with SIM card reader), you should be able to use that C+py stack to have userspace vowifi: https://github.com/phhusson/doubango https://github.com/phhusson/doubango
- LaF0rge 3y agoI've played with doubango for some time trying to get it to work against the flavor of IMS used in VoLTE / VoWiFi, and it is not all that close to it, even with various hacks applied from https://gitea.osmocom.org/ims-volte-vowifi/doubango/commits/branch/laforge/wip https://gitea.osmocom.org/ims-volte-vowifi/doubango/commits/... in which I tried to add a Linux kernel IPsec plugin as well as various other bits and pieces.
- dwbehappy 3y agoNot to take away from your excellent work, but what the hell is the point of VoWifi ? Why not just handle this with a well tuned user space app that runs on udp/whatever over any network connectivity you have already, whether it's wifi/cellular/pigeon carrier. It seems like its an entirely US-centric thing, motivated by a] cost savings from not using data on the cell network (not a problem for most of the world who have unlimited data plans cheap enough for everyone to afford) and b] some kind of vendor feature contest/lock-in type incentives. What is the selling point of it, I don't get it. WhatsApp/Facetime/Signal or similar voice calls are not perfect, they obviously do introduce some extra latency and inefficiencies compared to using that lower level data pipe, but it just strikes me as a very strange avenue for people to be going down with very marginal benefit (efficiency) but a ton of extra work. EDIT: Btw if its not clear, I fully agree with you that it, whatever it is, should be in userspace as much as possible, and as an open standard, I'm just trying to figure out why this stuff has been introduced in this way at all.
- wtallis 3y agoWhatsApp, FaceTime, etc. all require both endpoints of a call to use that app. VoWiFi lets you receive calls to your regular phone number from any normal phone. The fact that the last mile of the call is being carried over WiFi becomes an invisible implementation detail.
- upofadown 3y agoThe phones could just use the SIP protocol for voice. You don't need an accompanying chat app. The huge disadvantage of that is that the customer could then use any VOIP supplier for their phone calls. ... or none at all for SIP to SIP calls. That would create a competitive market in voice. A competitive market is the last thing any cell phone provider wants. They need to maintain their monopoly on the last mile connection. This might be an interesting idea for a government interested in improving this particular market. Forbid the provision of anything but reasonable latency data by a last mile provider. Establish standards. I note that jmp.chat, a provider of SMS and voice over internet connections, is toying with the idea of providing, pay as you go, data only plans as a complement to their primary service.