Live data from Hacker News

Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

blog.checkpoint.com

71–80 of 120 posts

Re: Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

#71

Earlier quoted context omitted.

A google scholar search for "amd security" turns up less than 100k results while a search for "intel security" has <2 million results.

ok, but what's the ratio of the number of Intel cpus running on something worth hacking compared to the number of amd CPUs?

This is subjective, but the ratio is probably heavily skewed toward Intel.

Mercury Research reports AMD's market share of the server processor market is a mere 4.5%.

If I were a hardware vulnerability researcher I would absolutely be focusing on Intel over AMD.

Re: Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

#72
post #27

Earlier quoted context omitted.

You are getting updates for the OS and kernel but not for device drivers. That's a big surface area for someone to hack your phone.

Imagine how good things would be if the drivers were open source and in the kernel. We would still have bugs but at least it would be possible to fix them.

Aside from the massive maintenance effort: what is keeping the community from taking all the driver code from the tons of official and unofficial code dumps and bringing them to mainline?

Re: Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

#73

Earlier quoted context omitted.

They did not.

It was a Google researcher mostly.

> Meltdown was independently discovered and reported by three teams:

Jann Horn (Google Project Zero), Werner Haas, Thomas Prescher (Cyberus Technology), Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology)

Spectre was independently discovered and reported by two people:

Jann Horn (Google Project Zero) and Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61)

https://meltdownattack.com/#faq-systems-meltdown

Re: Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

#75
post #24
post #21

Earlier quoted context omitted.

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.

Agree, we need open source hardware (like RISC-V) to mature in order to eliminate this class of vulnerabilities. I haven't heard much on mobile class RISC-V SOCs though.

RISC-V is an open source ISA, which means anyone is free to implement it, interface with it, customise it etc.

But most RISC-V devices are not open source as far as I know, as least currently. And a mobile class SoC would still be a very complex device, therefore with vulnerabilities (and also therefore with much less motivation for a company to open source the whole design). You'd have a similar problem as now.

That said, if someone wants to work with me on a RISC-V mobile class SoC (or server/supercomputer class) do get in touch, I'd love to do it :-)

Re: Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

#77

I wonder how would it be like to fill application forms for over 400 CVE numbers, or reading a security advisory with the first page exclusively occupied by CVE numbers. Well, seriously speaking, they'll probably group these vulnerabilities and apply a big one.

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

Re: Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

#79

Earlier quoted context omitted.

Imagine how good things would be if the drivers were open source and in the kernel. We would still have bugs but at least it would be possible to fix them.

Aside from the massive maintenance effort: what is keeping the community from taking all the driver code from the tons of official and unofficial code dumps and bringing them to mainline?

You can't just drop leaked code in to the kernel due to legal reasons. And even if the vendor does provide an open source dump of the source you still can't just drop it in to the kernel because it will not meet the code quality standards for linux. Vendors just hack it until it works and call it a day since they don't have to worry about unmaintainable code if they never plan to maintain it.

Re: Over 400 vulnerabilities on Qualcomm’s Snapdragon chip

#80
post #21

Time to switch to open source: https://en.wikipedia.org/wiki/Pinephone https://en.wikipedia.org/wiki/Librem_5

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.

There's Osmocom[1] for that. Sadly, it doesn't support modern PHY layers of the modem not modern baseband stack. It demonstrates, though, the possibility. I wish it had more traction.

[1] http://osmocom.org/

Post reply on HN