While they are still withholding info about how to exploit the bugs, there is more technical detail in their Defcon talk, "Pwn2Own Qualcomm Compute DSP for Fun and Profit" <a href="https://www.youtube.com/watch?v=CrLJ29quZY8" rel="nofollow">https://www.youtube.com/watch?v=CrLJ29quZY8</a>
Seriously I'm beyond pissed at the state of Android, patches and open-source compliance. If we are <i>lucky</i> 10% of current phone models will get any form of update. The rest will be vulnerable for <i>years</i> until the devices finally break.<p>And that's only the Qualcomm stuff. There is another CPU vendor beginning with M who is big in el-cheapo hardware - look at their Android kernel leaks, wherever you dig you find horrid, HORRID code.<p>Google should mandate full open source disclosure of all GPL'd components as part of the Play Store certification and unlockable bootloaders, otherwise this shit is never going to change.
“A single SoC (Software on Chip) may include features to enable daily mobile usage such as image processing, computer vision, neural network-related calculations, camera streaming, audio and voice data.“<p>Should be SoC (System on Chip)
Here's a link to the DEF CON talk: <a href="https://www.youtube.com/watch?v=CrLJ29quZY8" rel="nofollow">https://www.youtube.com/watch?v=CrLJ29quZY8</a>
There seems to be some confusion on the authors' behalf about what a DSP is, and what an SoC is ("software" on chip, as they call it...) I'm just nitpicking, of course.
I wonder if Apple/others knew about such vulnerabilities, and passed up on using the chip as a risk? Or, was it just dumb luck that they avoided this?
Time to switch to open source:<p><a href="https://en.wikipedia.org/wiki/Pinephone" rel="nofollow">https://en.wikipedia.org/wiki/Pinephone</a><p><a href="https://en.wikipedia.org/wiki/Librem_5" rel="nofollow">https://en.wikipedia.org/wiki/Librem_5</a>
Hardware vulnerability and issues are hard to address at times as it can be connected to other vendor hardware or softwares. I always wonder if these flaws are left in the design intentionally or its just a sneaky bad bugs.
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.
Would having an open source chip with a rolling release be more secure? Like as soon as the vulnerability is discovered you would push the fix and the next generations would already be fixed. Or would such frequent changes to the chip design be to difficult to mass produce, due to having to modify the production process?<p>This is coming from a point of view that Linux is quite a success and thus maybe the same philosophy could be used for hardware?
Shouldn't proper IOMMU usage prevent this?<p>In theory when properly configured the DSP or GPU should be unable to touch system RAM outside of buffers that are specifically assigned to them.<p>I'm not very familiar with the status of IOMMU on Android devices.
SpaceX designed custom SoCs for their isolated offshore/offworld network of Starlink satellites, <a href="https://spacenews.com/spacex-accused-of-poaching-chipmakers-employees/" rel="nofollow">https://spacenews.com/spacex-accused-of-poaching-chipmakers-...</a><p><i>> Broadcom filed suit ... claiming SpaceX hired a number of Broadcom’s top engineers to develop “a family of sophisticated, customized computer chips.” The two companies had been working together on the development of advanced computer chips for an undisclosed project, but SpaceX ultimately ended the collaboration.</i>