Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hardening cellular basebands in Android

security.googleblog.com

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Hardening cellular basebands in Android

#81

Post by klausa »

dwbehappy wrote: post #33
phh wrote: post #26

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…

Not 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 h…

I can make "regular" phone calls when on a different continent and on WiFi without paying any roaming fees.

Re: Hardening cellular basebands in Android

#82

Post by DiabloD3 »

wyldfire wrote: post #78
DiabloD3 wrote: post #47

Earlier quoted context omitted.

Qualcomm owns patents on an international standard. They sued Apple and arguably won, although they settled out of court. Apple had bought Intel's LTE unit and the patents that came with it, and Qualcomm and Intel both licensed patents into a common pool (and as such, any member of that pool did not owe any other member royalties); Apple inherited Intel's position in the pool and continued licensing patents to the po…

> Apple stopped paying Qualcomm the LTE blood money. "blood money"? Why so many tears for the most valuable business on Earth? When they picked Qualcomm for their 4G modem, the terms were clear. And then they decided to renegotiate the terms afterwards by telling their manufacturer to withhold the payments to Qualcomm. > _Qualcomm still sued and made money_. They negotiated a settlement, Qualcomm got less than they w…

> "blood money"?

Software patents are math patents, and math patents are not legal under US law, yet the USPTO continues to issue them. Many standards organizations require you to open the patents to anyone implementing the specifications managed by that organization if you wish to be part of the committee and introduce your technology to it, and the relevant policy here is a joint ITU-T/ITU-R/ISO/IEC governing agreement to do so.

3GPP was developed as a way to sidestep such mandatory agreements, while still being an ITU-managed spec. The company that is gaining the most advantage from this loophole is Qualcomm.

> Google "did" secure a win, didn't they? They took their ball and went home. They decided to take the Samsung Exynos SoC and modem for their flagship phone.

Yes and no. Google and Samsung are jointly putting pressure on Qualcomm that Apple couldn't. Both of them have patents that are part of the LTE patent pool as well, and key ones that would cripple Qualcomm if either of them pulled out.

Apple, through their Intel LTE acquisition, did not have as much leverage, even though Intel was the only other company was ready to compete in the 5G space and had patents relevant to 5G.

I believe Qualcomm, if they wished to push the issue, could also force both companies to settle. They may do so in the future.

> ... because they're better than the competition - including their acquisition? Is it your contention that Qualcomm somehow forced Apple to pick them over their own?

I do not believe so. Most of what was wrong with the first post-acquisition gen modems was Intel mismanagement of the product line (the same way they do to every other product of theirs). LTE benchmarks of the iPhone generation that contained both modems (and it was a random chance on which was in your phone) were mixed. Sometimes the Qualcomm modem was better, sometimes it was Intel.

It would be a shame if Apple abandoned the product entirely, and I don't think they did. I think this is part of the settlement. So, yes, to answer your question, I believe the settlement requires purchase of Qualcomm modems for x generations. The details of the settlement are not entirely public, other than there is a 2 year supply agreement.

You don't drop $1B on an acquisition just to get their patent portfolio and then settle and give up forever. You double down and continue working on polishing up that acquisition while the conditions of the settlement expire. I think in 2-3 generations we will see the return of the Intel modem; if we don't, I think Apple should go find themselves a new CEO.

Re: Hardening cellular basebands in Android

#83

Post by callalex »

lstodd wrote: post #62
sib wrote: post #58

Earlier quoted context omitted.

Europe is approximately 7% of the land surface area of the world. We don't all live in small, densely populated places :)

And US is 6.1% Your point?

Would you describe the entirety of the US as “densely populated”?

Re: Hardening cellular basebands in Android

#84

Post by LoganDark »

numpad0 wrote: post #50
phh wrote: post #26

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…

I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints. ALL of those desktop-derived event driven technologies, with deep call stacks and abusive use…

> the latter is how you get choppy audio

Tell me, if Discord can stream high-quality audio in real-time, what makes a phone call that much harder to handle, especially given how awful the sample rate is? Shouldn't an 8-bit micro from the 80s be able to handle that? Aren't there even already pieces of homebrew software for those micros that can handle audio of that quality?

Re: Hardening cellular basebands in Android

#85

Post by LoganDark »

posguy wrote: post #80
jchw wrote: post #74

Earlier quoted context omitted.

Hey, that looks really cool. I've been wanting to mess around with this stuff on PinePhone, which is in a unique position here since there are third-party images for the baseband which are mostly open source[1]. I've been especially interested in trying to reverse engineer what's going on with Google Fi on Android, but it is definitely a bit over my head, given that until recently I didn't even really know what an AT…

The PinePhone uses a really old, slow modem (the Quectel EG25). Why not get a modern Snapdragon x62 like the RM520, drop it in a carrier board, root the modem and do all the shenanigans you want? Useful links: https://github.com/natecarlson/quectel-rgmii-configuration-n... https://github.com/carp4/qadbkey-unlock

Because you can't use a Snapdragon in that way, that's not how Qualcomm's business works. There's a reason that very few (or no) "open" phones actually use Snapdragons and it's because it's impossible to obtain the firmware for these without layers of very restrictive contracts and NDAs. They're almost like NXP in that way.

Re: Hardening cellular basebands in Android

#86

Post by MadnessASAP »

csdvrx wrote: post #79
MadnessASAP wrote: post #70

Earlier quoted context omitted.

If I can put my paranoia cap on for a moment. The baseband processor having privileged access to the main processor may be a "feature" not a bug. It's a powerful processor, that is running constantly, has unlimited and continuous inscrutable communication with the network, is the gatekeeper for the main processors communication with the network, and it's firmware is practically required by regulations to be an opaque…

> The baseband processor having privileged access to the main processor may be a "feature" not a bug yes but iff with the qualifier of "in old systems, where permissions were a tree-like state where root/uid0 could see what unpriviledged users would do - by design" It's a dated design. More separation is needed, like what was achieved for virtualization or containers (namespaces) > it's firmware is practically requir…

I don't disagree with any of that. My point being that the people with the power to make the change have no desire too.

Re: Hardening cellular basebands in Android

#87

Post by GoatOfAplomb »

numpad0 wrote: post #50
phh wrote: post #26

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…

I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints. ALL of those desktop-derived event driven technologies, with deep call stacks and abusive use…

> is probably because of lags those stuffs introduce

There is likely some truth to this, but I think the bigger reason for these things is that Qualcomm can't be arsed.

Re: Hardening cellular basebands in Android

#88

Post by yMEyUyNE1 »

acaloiar wrote: post #16

For those who don't eat and breathe this stuff, "basebands" are the processors that do all the cellular radio stuff on your smartphone. They're separate from device CPUs (referred to as the Application Processor), and are loaded with firmware. This post is about securing the firmware that runs on these little processors. When baseband firmware is compromised, it can lead to complete device compromise.

Is there any way to isolate or sandbox it, so that the rest of the phone/device is not compromised?

Re: Hardening cellular basebands in Android

#89

Post by atoav »

LoganDark wrote: post #84
numpad0 wrote: post #50

Earlier quoted context omitted.

I'm just guessing here; but the reason why it's not implemented in userspace, not written in Rust, not using IOMMU, BP is allowed full DMA, the system is split into AP and BP in the first place, etc etc, is probably because of lags those stuffs introduce - difficulty of meeting and maintaining required realtime constraints. ALL of those desktop-derived event driven technologies, with deep call stacks and abusive use…

> the latter is how you get choppy audio Tell me, if Discord can stream high-quality audio in real-time, what makes a phone call that much harder to handle, especially given how awful the sample rate is? Shouldn't an 8-bit micro from the 80s be able to handle that? Aren't there even already pieces of homebrew software for those micros that can handle audio of that quality?

For me it feels just wrong? Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive.

If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? So now you got bad software in a sandbox that may or may not be safe and is less performant than the low level variant. Maybe the software is bad in a kind that allows abuse despite the sandbox, congrats now your baseband lies to you.

The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. Embedded programming sucks, but we have Ada, we have Rust and we have a chance to do things that are both safe and performant.

Re: Hardening cellular basebands in Android

#90

Post by wrboyce »

lstodd wrote: post #49
eightysixfour wrote: post #42

Earlier quoted context omitted.

VoWifi is neither US centric nor purely about efficiency - it allows you to make calls with your phone to another phone via a third party network when you don’t have cellular connectivity. For example if you have poor cell coverage at your home or office, you can still make and receive calls via a wifi connection using your phone number instead of forcing everyone to sign up for some third party service.

Well, this sort of reinforces the point - there are about zero places in Europe where you have Wifi but do not have cheap almost-unlimited 4G/LTE. In fact it's wifi that's dying out here, the only thing that keeps it alive is that in a cafe setting it's still somewhat faster, and it eats a bit less battery.

I live in the UK and pretty much rely on VoWifi to make/receive calls when at home. I can also think of a few places within an hours drive where my reception drops to “No Service”.

You are completely wrong in your assertions.

Post reply on HN