←back to thread

328 points jerlam | 1 comments | | HN request time: 0.208s | source
Show context
joecool1029 ◴[] No.45271165[source]
Might as well say it since nobody else commented about it, but modem/soc vendors are huge limiting factor on longterm android support. Qualcomm maintains these updates for only a few years, basically nothing earlier than around 2020-2021 gets kernel driver or modem updates.

Of course it's still up to phone manufacturer to integrate these changes, but it puts an effective security support timeline on even 3rd party ROM's like lineageos. They can cherrypick, but it's not as secure once that support ends.

Apple has almost everything in-house (except until recently, modems). So they have a ton of flexibility in continuing to provide updates.

replies(7): >>45271246 #>>45271373 #>>45271509 #>>45271512 #>>45271695 #>>45271719 #>>45271849 #
treesknees ◴[] No.45271373[source]
My problem with this argument is many of these types of CVEs have nothing to do with baseband firmware or drivers or anything else controlled by Broadcom. Google could still patch security issues in the parts of the system most exposed to attackers, namely the libraries and apps in the OS itself.

I’d be more afraid of a zero day image parsing bug in messages, where I could be exploited with a drive-by spam text or hyperlinked image, than some theoretical baseband attack by someone in a privileged cell network system.

replies(3): >>45273167 #>>45273616 #>>45273932 #
1. lloeki ◴[] No.45273167[source]
The problem is that baseband or whatever drivers are made in kernel trees that are essentially forks of the kernel at a certain point in time.

This means that any fix needs to be backported to that special tree, irrespective of whether the Broadcom code is impacted, which may prove challenging when you end up having not just one but many trees, each at slightly different levels of outdatedness.

The approach clearly does not scale.

The solution would be for Broadcom to be diligent and forward port their tree to current mainline or current LTS at a minimum but they won't do that.

See how the RPi kernel is generally stuck at a special old version (e.g 6.6 for pi4, which is quite reasonably a LTS but then there's 6.12 as LTS already)