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.
This is a thing I think people constantly underestimate... Intel's cores are not necessarily dramatically more broken than everyone else's chips, they just pay for more auditing and public research.
A quick survey of the papers published in 2019 and later (i.e., post Meltdown/Spectre, inclusive) listed at [1] indicate that Intel contributed financial support to the majority of them. ARM was the second-most corporate contributor, followed by AMD.
> 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)
This is very much an opinion, not a fact. "Intel is only in trouble because they got caught, AMD is surely incompetent as well, but hasn't been found out".
My point is that there is more academic research on Intel processors than AMD. For a hacker, an Intel vulrability would of course be more lucrative than a AMD one.
That's a good point, about half the results go away when you add "processor" to the query. Interestingly, the same happens for the AMD query so the ratio is still similar.
That number is literally the most meaningful number there. Meltdown caused more scare than all of these 400 bugs described here, just because intel is not expected to have any sort of vulnerability and the people who really care about security chooses intel(not talking about self described privacy pundits on HN, but military and banks). There had been much more research on intel security than all other chips combined.
I dont think it has much to do with competence, the order of complexity in these chips are reaching super human levels of intellect to decipher. Finding vulnerabilities is hard but safeguarding against them is even harder. Take 'spectre' for instance, it is a fundamental problem with the speculative architecture can't really get rid of it.
Even if they wouldn't, I imagine the exposure is enough. Windows, Android, Linux probably have more eyes on them than all the other software in the world, combined.
"If you want half the world's hackers to audit your code, put it in an Apple product. If you want all the world's hackers to audit your code, put it in a Nintendo product."
I don’t doubt that they have more independent security analysis than just the bounty program; but using it as an argument that they’re paying people is not realistic.
Bug bounties are very different than auditing. In an audit, there is a contract in place with specific analysis objectives based on agreed-upon criteria. I find it unlikely anyone in the industry would have more experience than Intel about CPU manufacturing, although there might be security consulting firms that are advanced enough to merit a real corporate NDA. But given the breadth and depth of their IP, even that seems unlikely.
But I would still really be interested to know who Intel hires to audit their products, if this is true. I'd like to do that kind of work.
Isn't this why apple doesn't trust the CPU with secure functions and has dedicated hardware for it? So a vuln in the cpu won't expose the encryption keys bypassing face id.
Hard to tell anyone's intentions, but that's probably, at least partially, a side effect.
Apple seem to use security primarily for two things, marketing, and to ensure they have control over the platform, and the developers who write applications for it.
Maybe that's three things? Anyway, the totality of what they do in security isn't user centric enough that the reason for external security hardware would be to primarily increase the user security. Obviously they have to do this (increase user security) to make it palatable to the customer, but there's a certain asymmetry in their actions that makes it seem unlikely that actual increased user security was the original goal.
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.
It's even more intentionally misleading than that. The SDK generates wrapper libraries that allow you to interface with your code running on the DSP. Some of the wrapper functions generated have vulnerabilities. The 400 vulnerabilities are the few vulnerabilities found in the SDK template multiplied by how many different generated wrapper libraries they found.
So you fix the handful of errors in the SDK templates and all the 400 vulnerabilities go away.
