Over 400 vulnerabilities on Qualcomm’s Snapdragon chip (opens in new tab)

That's what I came here for as well!

Way would you want that?

> horrid, HORRID code

Heh, I once found a "feature" in a kernel driver in my Xperia (with a SoC from the company with a name starting in M) that allowed you to read arbitrary kernel memory from userspace, by passing the appropriate structures via a ioctl interface. Didn't even have to dig around too much.

Ah well, at least I got a t-shirt from Sony.

That is never going to happen, when Treble came out we thought it would change, but since they don't force OEMs to actually deliver updates, everything stayed the same.

When questioned about this on the Android Platform 11 AMA last month, they stated that they think OEMs freedom is what makes Android a rich ecosystem.

So there you have it. Can check by yourself on Reddit.

Are you referring to the fabless bunch whose name starts with M and ends with ediaTek? :)

Google are the ones that went on an Apple-esque crusade to extinguish all GPL in AOSP.

Still getting updates for my one plus 6. YMMV.

I think you have a point here. When they say "DSP chip" instead of "DSP core inside the Snapdragon chip" it makes me wonder what else they got wrong. I don't think the oversimplified language is any more approachable here.

(As it happens I read the slides and this is a legit vulnerability but you'd never know it from the press release.)

From Apple's perspective Qualcomm has been insufficient for a long time for many reasons, the security issues here would only be one of the many factors involved in the decision to do their own development.

For what it is worth, a modern chip as complex as the A* series is essentially guaranteed to have vulnerabilities. Maybe not 400, but definitely not 0.

Looking at the slides from a different article, these are not really in the chip per say but in the SDK. So any lib compiled to use the chip would be affected but not really a hardware issue. Basically fuzzy testing found 400 library calls that fail with segfaults. These can sometimes (but not always) be modified to do a takeover, but I didn't see anyone claiming to have done that.

The implication is that Apple's own chips are somehow bug-free, which they probably aren't.

If you have connections to the real infosec world. They'd avoid it.

An Open Source OS can help, sure, and is a start. A DSP is a programmable hardware device. Both phones to which you linked use variants of ARM processors and then use third-party baseband systems. You're not getting rid of closed-source hardware vulnerabilities by replacing Android or iOS.

That's not a panacea. OpenSSL was completely open source, and it took, what, 2-3 years for Heartbleed to be discovered and rectified? And it's a major building block of the internet.

For open source to help, people have to actually review the code.

Can you make phone calls on the pine phone?

National security is and will continue to be a joke until there is strong regulation forcing all involved vendors to fix their crap for as long as their devices are used.

unless they force everyone to buy Apple phones ;)

They have a lot too, a new one just popped up a few days ago https://www.bgr.in/news/apple-products-have-a-new-unpatchabl...

I'm not sure if anyone has compiled a list of how many

Keep reading; there are 6 CVEs assigned. The 400 is different binaries that have the same vulnerability.

Hardware is different in that it can't be updated once it's leaves the factory and has to be "right first time".

first you have to have open source chip, and then have fabs willing to want to make it (and someone willing to pay them up front), and have phone makers want to use it..

And no changing chips every few months possibly breaking compatibility (people working around your bugs) is not a feature that a lot of hw designers want.

This may change eventually. I have high hopes for RISC V but we will see

It's dependent on the SoC whether there's IOMMUs at all and whether they're rigged up to all the bus masters in the system. A lot don't have them as it was seen as a virtualization feature rather than a security feature for the longest time.

You mean GrapheneOS.

There are other alternatives, e.g. Samsung.

What's your implication here? SpaceX perhaps saw a bunch of security vulns and decided to DIY?