Get the top HN stories in your inbox every day.
mschuster91
phh
> - there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices
For basebands yes. I'll complete this for a quick overview for IMS/VoLTE, which is often in baseband, but not always. (And VoLTE is at least partly what the article is about, and the last public Pixel remote flaw was caused by VoLTE)
Just to give a quick approximate overlook:
- If you're on a Verizon-branded device, Verizon probably made their own IMS implementation mandatory [1]
- If you're on a Samsung or LGE-branded device (no matter the SoC), they use their own IMS implementation [1]
- If you're using a non-Samsung-branded Samsung Silicon device (=SLSI: Pixels, Moto One Action and few others), they use a different IMS implementation than the IMS Samsung uses in their smartphones
- In other cases, you're indeed likely using the IMS/VoLTE implementation provided by the baseband/SoC vendor
As far as I know, the implementations I've marked with [1] are at least partially [2] done in userland in application processor rather than in modem, but it's hard understanding really. The ones that are not marked with [1] are in modem afaik.
[2] Partially meaning the annoying protocol stuff, but audio encoding/decoding + RTP encapsulation might remain in hardware
csdvrx
The ASAN etc. are nice suggestions for parsing the OTA messages delivered over a link. It really mattered with serial links
But if there's a CPU, and the link has access to the IO space, I'd prefer to first have IOMMU to avoid giving too much trust to the baseband: a takeover or exploit of whatever's parsing the messages would then be a lesser concern.
Most 4G/5G modems are connected straight to the PCI bus and I believe that's far more unsafe: with no IOMMU, in case of a baseband takeover, it's game over.
Old serial ports on well-known IO (ex: COM1 0x03f8, COM2 0x02f8) seem to have provided a natural checkpoint and chokepoints.
Or am I missing something obvious?
twothreeone
It's actually strictly worse: even if they had an IOMMU and the drivers were implemented correctly, phone vendors provide remote access tools as part of their firmware stack (e.g., see https://www.fsf.org/blogs/community/replicant-developers-fin...). To reiterate one of the other commenters, as long as users don't control what code runs on the baseband, they do not in fact have ownership of the device. The same holds for anything else that has a baseband (such as most modern cars). This sentiment is publicly communicated by telco's and manufacturers and convenient for regulators.
JoshTriplett
That's true, but as long as the baseband doesn't have access to the rest of the device, there is at least a limit to how much damage it can do, which is a good incremental step. If it can't exploit the OS, then worst case, it has access to network traffic (just like the next router in the chain, which is why all the traffic should be encrypted), and it has the ability to help locate the device against the user's wishes (but so do the cell towers).
Rewriting baseband firmware is also a great opportunity to make it Open Source, and I hope that happens as well.
twothreeone
It looks like https://osmocom.org/projects/baseband is still somewhat active.. they mainly develop for the TI Calypso (Motorola C123 and some others). My understanding is that all "modern" (meaning 3G and up) modems are basically sealed black boxes.
devit
At least modern Google Pixel phones have an IOMMU (https://grapheneos.org/faq#baseband-isolation)
csdvrx
> A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way
YES!
jtriangle
Take a few steps back, the obvious problem is that all phones are chock full of mysterious black boxes that the owner of the device has zero say over.
Android has the problem of being too open to prevent backwards implementations and shitty, vulnerable, and bug prone code, but not open enough for anyone with the incentive to fix those issues to actually be allowed to fix them.
I see the eventualities to be either Google locks down android significantly, and the market shifts to something more akin to Nvidia's board partner model, or, it opens way up, and device manufacturers open source their implementations of various system devices in order to crowd source fixes/improvements/etc. The former is much more likely than the latter, but, as a consumer, the latter would be preferable.
phh
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 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
numpad0
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 of interrupts, tend to run NOT like a marathon runner, but like an attention deficit man, and the latter is how you get choppy audio.
IIUC, Nokia in '00s already used an architecture that baseband OS and application OS(Symbian) would run on the same CPU, with RTOS below the application OS forcing regular switch to baseband or something, because baseband code is synchronized to physical IRL time, managing physical phenomena, and the user, can wait.
If anyone's going to move phone signaling and audio processing to AP, they'll have to first show the embedded guys that their fancy stuff is better than the existing realtime stuff, and is not an elaborate prank. Which, I think, isn't easy. I mean, one of news for Raspberry Pi 5 was addition of a programmable I/O processor for realtime/low-level tasks, not removal of.
GoatOfAplomb
> 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.
LoganDark
> 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?
atoav
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.
phh
There are two lags to take into account. Lags at connection, and lags during the call.
Connection is what is very complicated to do safely, but once its setup, except for some signaling, it is much simpler [1].
The architecture used by some people (I wouldn't know exactly who does what, it's all muddy) is that the connection/signaling is done in application processor, but the Encoding/Decoding + RTP is done in baseband processor. You do get a bit of additional of lag at connection (but anyway you have an UI to show), but you can keep your real time audio guarantees.
[1] That's for volte. For vowifi, that's more complicated, but anyway talking about lags over wifi...
the8472
> 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.
That doesn't seem likely. All those technologies (except userspace maybe) work fine for realtime constrains down to microseconds. If your constraints are in the nanoseconds (wireless signal processing stuff?) you probably have to use some local SRAM anyway and thus not need to touch the system memory.
jchw
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 command was :) I'm guessing since it's Google the carrier stuff is mostly for fallback and all of the actually interesting stuff is done using protobufs over a data connection. (Fi is also interesting because you can make phone calls on the web over WebRTC. I wonder if that's some kind of gateway to SIP, or what.)
[1]: https://github.com/the-modem-distro/pinephone_modem_sdk
(Note: I didn't dig deep enough, so it wouldn't surprise me if the blobs in this are actually where the interesting stuff happens, but it's still probably a great base for experimentation nonetheless.)
posguy
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...
LoganDark
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.
dwbehappy
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 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.
alufers
I used to live in an old apartment block with thick concrete walls, and away from a cellular base station. VoWifi was really helpful if I wanted to make calls from my home. I guess I could use WhatsApp/Facetime/Signal, but the insurance agent won't call me on WhatsApp from her landline phone :)
And it is not handled by an app on your phone, because of legacy reasons. I believe that, before LTE was introduced, 2G and 3G had a distinction between IP and voice traffic, so the baseband handled the voice transmission. Then they thought that LTE should be IP only and voice should be sent as VOIP over it, but it still had to be handled by the baseband for backwards compatibility with 2G and 3G. And then they came up with the idea that the VOIP traffic could also be piped over Wi-Fi (through the main processor of the phone), and so VoWi-Fi was created.
numpad0
I think it was lots of parallel development - some mid-to-late 3G phones had carrier hand-rolled Wi-Fi calling, some had femtocell support instead, LTE was to be just faster packet-only Internet mode for 3G, became its own thing too late which necessitated CSFB, and then Wi-Fi calling became reimplemented as part of standard, etc.
thaumasiotes
> I guess I could use WhatsApp/Facetime/Signal, but the insurance agent won't call me on WhatsApp from her landline phone
Huh. I would expect that it's more common for the insurance agent to have WhatsApp (or equivalent) as the only option than it is for them to refuse to use it in favor of the telephone network.
wtallis
WhatsApp, 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
The 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.
BobbyTables2
I think your concerns are misplaced.
Things like TCP/IP and DNS are child’s play compared to the complexity of cellular baseband firmware — even for just a single 2G/3G/4G standard.
The SIM card layer is also another nightmare in itself.
eightysixfour
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.
lstodd
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.
yxhuvud
> Not to take away from your excellent work, but what the hell is the point of VoWifi ?
The point is that your phone should continue to work even if you are deep inside a building without coverage. Or that you should have connectivity if you for some other reason have good wifi coverage but bad cellular.
Now, the protocol choices I won't defend, it is layers upon layers of complexity that I don't know enough to understand what is motivated or what is bad.
klausa
I can make "regular" phone calls when on a different continent and on WiFi without paying any roaming fees.
LaF0rge
I'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/... in which I tried to add a Linux kernel IPsec plugin as well as various other bits and pieces.
pomian
That looks great! I have a pixel 4xl that will not allow enabling VoWifi. (Maybe old sim card, maybe Graphene.) As you mentioned, great for other builds. PinePhone, etc. Going to try...
acaloiar
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.
uncertainrhymes
This particular comment became the first Google search result (or 'featured snippet') for me for "What is Android Baseband" -- weirdly claiming to be posted four hours ago when this comment was two hours old.
That is mindblowing to me. Full credit to the poster for becoming the canonical answer, but I'm not sure how I feel about Google picking comments without even some kind of page-rank-weighted attempt at deciding what is 'best'.
acaloiar
Yikes. Google put my grug brain [1] synopsis on full display?
Google, please use less grug brained explanation of baseband processors [2]. ty
voxelghost
For me, googles 'featured snippet' for 'What is Android Baseband' is extracted from the almost unreadable https://www.mi.com/global/support/faq/details/KA-11986/
I think the parent comment is almost more informative.
deepsun
Google still employs a lot of manual page rankings.
rollcat
Also probably enough Googlers just hanging out on HN.
SushiHippie
FastGPT from Kagi answers to this question:
"Baseband is the firmware that controls the cellular radio functions of an Android device. It is responsible for things like connecting to mobile networks, making phone calls, and sending/receiving SMS messages. [1][2]
The baseband firmware resides on the same storage (eMMC) as the Android operating system but runs independently on a separate baseband processor. It communicates with the Android OS through shared memory and AT commands. [3][4]
Baseband versions are different from Android build numbers. The baseband version refers specifically to the firmware running the cellular radio hardware. [5]
Baseband firmware has been found to contain vulnerabilities that could allow remote command execution if exploited. However, Android devices from reputable manufacturers like Google/Pixel generally receive frequent baseband updates to address such issues. [6][7][8]"
[1] https://www.quora.com/What-do-baseband-version-and-kernel-ve...
[2] https://www.reddit.com/r/AndroidQuestions/comments/1wzmp7/wh...
[3] https://android.stackexchange.com/questions/219230/where-is-...
[4] https://stackoverflow.com/questions/24569075/how-mobile-os-t...
[5] https://forums.androidcentral.com/threads/difference-between...
[6] https://techcrunch.com/2019/11/08/android-baseband-flaws/
[7] https://www.reddit.com/r/GrapheneOS/comments/11op7yz/remote_...
[8] https://news.ycombinator.com/item?id=38616922
And the last link is this hackernews post!
winter_blue
The device drivers for these baseband processors really should be run inside virtual machines. Most modern processors support IOMMUs [1], and assuming that (hopefully) modern cellphone processors have IOMMU support, the operating system should be updated to running device drivers in an isolated container or VM.
With Linux not being a microkernel there’s a high likelihood the device driver expects to run in kernel mode. We probably will need to have a little a Linux VM containing the driver, and create a system that propagates its I/O back to the host. It’s a lot of overhead, but I’m not sure if there any other way of ensuring secure device drivers on Linux.
[1] Ancient device drivers expected full unrestricted DMA, i.e. full unlimited read/write access to RAM. But IOMMUs (VT-d on Intel) let us pretend to give such device drivers full DMA while isolating them.
ignoramous
Android has transitioned to secure DMA-BUF (after much controversy with ION), which more or less alleviates the need to use a mutually-untrusted VM (pKVM https://youtu.be/edqJSzsDRxk) for Baseband isolation?
Note though, OEMs are known to run 'device management' stuff with elevated privileges (not just the Baseband). Ex: see this write-up on Samsung RKP (realtime kernel protection): https://archive.is/6ClWm
As for 'drivers', the GPU drivers have also a viable attack vector: https://news.ycombinator.com/item?id=34490471
numpad0
It's usually Linux that gets isolated by classical(not like modern VMM) monitor and kept away from baseband, not the other way around.
ksjskskskkk
> , it can lead to complete device compromise.
lile they had on the flagship pixels just 8mo ago.
the csv google downgraded the severity because there was a work around of "disabling 5/4g" in a market that offset 3g. heh.
gruez
Source? If you're talking about this[1] from a few days ago, all the vulnerabilities were DoS (ie. they can crash your phone). Hardly "complete device compromise".
gavinsyancey
Probably this one, from March:
https://googleprojectzero.blogspot.com/2023/03/multiple-inte...
> The four most severe of these eighteen vulnerabilities ... allowed for Internet-to-baseband remote code execution
Affected the Pixel 6 and 7, among other devices.
ksjskskskkk
the other commenter found the right source. but also, remember all DoS wich corrupt memory ARE complete compromise. the original researcher just gave up before they found how.
baffles me that people here fall for this simplistic excuse of "it just corrupt memory"
or things like "the modem is isolated from the phone". sigh. how do you think they configure your phone via a text message? the protocol is safe but the payload is crazy powerful and trivial to abuse.
no phone expects the modem to be an adversary. and every modem firmware is wide open. everyone just pretend it's not and hope the NDAs will work keeping the modem security holes from falling into the wrong hands. heh.
vlovich123
> When baseband firmware is compromised, it can lead to complete device compromise.
I believe that’s generally only still true for Android and fixing that is what this is talking about. I don’t actually know but I recall when I worked at Apple many years ago that the baseband was firewalled already for this exact reason.
Edit: can’t find any reports of a baseband compromise for iPhones although I wouldn’t rely on a 30 second DuckDuckGo search to state something definitively.
danielheath
There have been, but iPhones all have the baseband connected via an MMU, so even if you get code execution it's hard to exploit usefully (you can see/modify packets, but nearly everything is encrypted these days).
Some android manufacturers also have an MMU but others connect the baseband directly to main memory, leading to total device takeover when the baseband is compromised.
iforgotpassword
I can't find any trace of this with a quick Google search, but I'm super sure I read about the very first iPhones having the baseband module talk to the soc via USB as an isolation measure, since USB didn't have DMA or anything "dangerous". Anybody else heard that, or am I hallucinating?
tptacek
It can but doesn't necessarily, right? There's a variety of interconnect and IOMMU architectures here, so it's not a given that a baseband processor has or is one step away from unrestricted access to the whole platform.
csdvrx
it can't and it shouldn't IF IOMMUs were properly used
MadnessASAP
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 blob. Seems to be pretty much the ideal place for nefarious deeds.
fulafel
Indeed, hardware security building blocks are just that, necessary but not sufficient. Eg Unix and Windows took a very long time from "we have hardware MMU and are using it for some stuff" to "we have a real world tried and tested, somewhat working multiuser security separation".
yMEyUyNE1
Is there any way to isolate or sandbox it, so that the rest of the phone/device is not compromised?
undefined
therealmarv
Guessing the Tensor G1..3 based Android phones are not affected by 5Ghoul? https://asset-group.github.io/disclosures/5ghoul/
mschuster91
The Pixel lineup uses Samsung modems.
ksjskskskkk
it probably is, but you won't get the usual academic work for free as you get with more common platforms.
xiipie
All good points, but why write this in an 'open letter' style to unnamed baseband vendors?
Does Google not have sufficient contact with key decision makers at Qualcomm, MediaTek, Samsung, etc. to encourage them to improve the the security of their baseband firmware? Those are the people who really need to be convinced.
DiabloD3
It isn't about "sufficient contact". Google knows exactly who to call at any of these companies, and those people will pick up the phone when they see Google is the one calling.
Qualcomm actively botches the security of their products as per request of many governments.
The purpose of the letter is to openly shame these companies without directly accusing them of foul play, instead of gently painting them with the brush of mere incompetence, mere lack of knowledge how modern tooling works.
abdullahkhalids
What's stopping two trillion dollar corporations who assemble/build their own phones and phone OSes from designing/manufacturing their own secure baseband chip and getting it certified?
DiabloD3
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 pool with no change. Apple stopped paying Qualcomm the LTE blood money.
_Qualcomm still sued and made money_.
If Apple can't secure a win against Qualcomm, how the hell can Google?
Also, Qualcomm will _never_ license patents (under FRAND or otherwise) to competing vendors; the only way to be allowed to make LTE modems for the west is to be part of that pool.
Oh, and btw? Apple was making their (Intel-based) modem in-house for like two generations while that whole thing happened. They're back to buying Qualcomm modems again.
xiipie
> Qualcomm actively botches the security of their products as per request of many governments.
Interesting, I was not aware that's what they're doing. Is there evidence of this?
avidiax
I doubt there's publicly available evidence.
Assuming incompetence before malice, I'd say that Qualcomm and the other 5G baseband manufacturers have such a moat around cellular modems that it doesn't need to be secure. It's not a competitive advantage. A security critical application simply assumes that the network and the 5G baseband are compromised.
undefined
pedrocr
Isn't all of this obvious for a modern C or C++ codebase? Is the state of Android baseband so bad that these are useful suggestions? Are they at least properly ring-fenced from the host CPU/RAM these days?
DiabloD3
The problem is it isn't "Android baseband", it doesn't run on the CPU that Android does at al. Instead, an entire second whole computer (not even a "microcontroller", in many cases they are just as powerful per-core as your real CPU) that runs a closed source realtime OS that Google (et al.) has zero visibility into.
Some phones straight up admit the baseband is actively hostile and only communicates with it via serial (which leads to poor performance, but a secure phone). Some phones, such as any using a vanilla Qualcomm Snapdragon setup of any generation simply don't care: the baseband firmware has more holes than a slice of swiss, and the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM.
This is a known attack vector used by state sponsored actors, including the US breaking into the phones of so-called "drug lords" to ease drop on them live from their own phones , without a call being active.
Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship.
csdvrx
> Until basebands are mandated to be FOSS for security and safety reasons, Google is just moving the chairs around on the deck of a sinking ship.
I agree. I couldn't see much of a point in the techniques discussed when there's a huge elephant in the room, and you can't fix it, so I thought I was missing something obvious.
I wasn't: it's just security theater, doing something for the sake of doing something, while there's a big pink elephant in the room you should not look at:
> the IOMMU refuses to allow the OS to restrict the baseband processor's view into system RAM.
And I can't find any valid technical reason for that elephant to be in the room.
There shouldn't be limitations for accepting IOMMUs: "be liberal in what you accept and conservative in what you send"
> Some phones straight up admit the baseband is actively hostile and only communicates with it via serial
That looks like a fair assumption. You wouldn't have daemons listening as UID 0 on all ports, accepting then running the random binaries they get, so why would you magically assume it's ok to do the exact same but with baseband instead of a daemon?
> (which leads to poor performance, but a secure phone)
Can you recommend some phones?
I wanted to get a better understanding of the stack so I bought an original pinephone, with the grand plan of installing arch on it (for fun!)
Could it be made to work like that?
A simple search only found https://www.reddit.com/r/pinephone/comments/har9aj/pine_phon... which concludes with "I don't think the Pinephone can provide any of the security requirements of Graphene OS ( iommu isolation etc )"
What should I buy to explore the concept of IOMMUs on cellphones?
galangalalgol
Graphene recommends a modern pixel. If they can properly restrict memory access on those phones and the baseband doesn't have any direct access to the mic via analog signal or similar, then it probably can't listen in on either incoming or outgoing communication, that should all be encrypted before it hits the memory right? You could still be located and identified, but they don't need to compromise your baseband for that.
DiabloD3
Arguably, any system that uses a Qualcomm SoC is not secure: either they do it on purpose, or they truly are incompetent, or it is a mix of both. No Qualcomm phone I've ever owned I've been truly happy with from the SoC SDK perspective (makes the job of community ROMs a thousand times harder).
I do consider the Pinephone and Pinephone Pro secure, however. It doesn't use Qualcomm, and the broadband SoC is an isolated part. Allwinner and Rockchip do not have the security nightmare track record that Qualcomm does. They also ship with Postmarket instead of an Android that isn't security focused, which is nice.
The only problem with Allwinner and Rockchip is they are both Chinese companies that may be tampered with by the Chinese government. Qualcomm and Mediatek just have a record, today, of security flaw after security flaw.
The new Samsung-made SoCs in the new Pixels are also an interesting choice. They do not use the Samsung TPM, instead opting for Google's newest version of the Titan TPM. Shortly after the Pixel 6 came out, Google Project Zero issued a story about the Samsung TPM having security issues. Hmmmmmmmmmmmmmmmmmmmmmmmmm.
undefined
undefined
BobbyTables2
I feel like this article was surely written by someone who has never actually looked at cellular baseband firmware, listened to researcher’s talks, or even stayed at a Holiday Inn.
Cellular hardware companies have to care first… As in NOT using crappy 32bit processors without virtual memory.
Things like non-executable stacks have merit… ASLR has merit…
Then, we can start yapping about compiler flags…
undefined
rubatuga
Or you could just use a USB cellular modem.
Get the top HN stories in your inbox every day.
Anyone surprised by basebands being vulnerable should know these things:
- there are only three big players in town: Qualcomm, Mediatek and Samsung, and the latter is pretty rare to find outside of Samsung's own devices and the Google Pixel lineup (where they also have been implicated in security [4] and battery performance [5] issues)
- Qualcomm is infamous for suing anyone including Apple for patents crap, which is how this oligopoly formed in the first place, and why there's barely any competition
- It's not the first time serious vulnerabilities have appeared in baseband chips [1]
- and finally, to a possible cause, Qualcomm's development practices [2] are even worse than what's reported about Oracle [3], if these (anonymous) HN comments are to be believed.
[1] https://www.bleepingcomputer.com/news/security/qualcomm-vuln...
[2] https://news.ycombinator.com/item?id=38607205
[3] https://news.ycombinator.com/item?id=18442941
[4] https://www.notebookcheck.com/Google-warnt-vor-massiven-Sich...
[5] https://www.nextpit.com/google-pixel-8-pro-5g-modem-battery-...