Attacking the Qualcomm Adreno GPU | Hacker News Reader

Attacking the Qualcomm Adreno GPU

googleprojectzero.blogspot.com

63 pointsarchimag022 comments

Guang Gong keeps disclosing many remote Chromium/Android zero click vulns, every year, which could've earned him millions on zerodium, and even more if put to real use.

Deserves respect at least.

He will be getting the same at GPZ, trust me.

"We can offer a few additional recommendations: Transparency and openness: (...) More generally, the competitive benefits of a closed platform approach to hardware internals should be reassessed in 2020. This balance may have been historically appropriate when the GPU was not in the critical path for security, but today billions of users are relying on the GPU to uphold the operating system security model. "

This.

At least the GPU stuff is getting some scrutiny.

Their modem code is a security nightmare and outside Qualcomms modem teams nobody is allowed to see it.

Yeah I think it is pretty nuts that people are willing to use CPUs that have those modems on the same die.

The simple solution is memory isolation - let the modem be as insecure as you like, but anyone who breaks into the modem can only see your network traffic (hopefully all encrypted anyway) and nothing else.

Sadly todays qualcomm hardware has no real memory isolation at all - any bit of on-chip hardware can see all memory.

It isn't perfect, but it's far easier to do that than properly secure a multi-million lines of code codebase with a substantial amount of unpatchable hardware...

There is definitely memory protection in the modem. If nothing else because the code is so horrible it crashes all the time.

Three is even a hypervisor for hexagon but I don't think it is used.

As someone else said, it's not a security barrier between the ARM core and the radio hardware bits... It's more a tool for remapping stuff to make system design easier, and as a way of protecting against evil hardware outside the SoC.

I believe it can prevent the ARM core tampering with private radio hardware memory, but not the other way round.

I think Qualcomm XPUs can be used as barriers (pretty much the same way SMMUs are used).

XPUs + hypervisor should be enough, assuming Qualcomm enables them and configures them correctly.

There is an IOMMU on snapdragons, as the article says, but it is the IOMMU mapping itself which they attack.

This itself is kind of mind boggling how they let the device overwrite its own IOMMU configuration, effectively nullifying IOMMU's purpose, and its provided safeties.

It's like fencing your house with 10 meter high walls, but leaving the key lying in front of the gate.

So, like you say: they don't have an IOMMU, although they have some dingus which is called an "IOMMU".

I wonder how secure new nvidia "security" features like MIG actually are. With people running real-time audio/video transcoders on GPUs for multiple connections, I wonder whether it is possible particularly crafted video connections to leak the video of other channels being processed by the same GPU.

Even if one were to encrypt all connections, these will probably need to be decrypted on the GPU for processing.

Next time Project Zero finds an iOS bug and people suggest it is a commercial hitjob, point them at this.

Qualcomm (and all Android vendors) look like they have been screwed by this. (To be clear - they are screwed because their processes are to slow to get security updates out).

Maybe you have not used Android lately?

I have two phones and a tablet, all mid-range devices from 3 different vendors and all are on Android 10 with at least August patches.

Edit: both phones are also more than 2 years old.

I have a Pixel.

My comment referred to the timeline outlined in the post, in particular this part:

Qualcomm gives an update on the progress of a microcode based fix. The plan is that the fix will be available for OEMs by September 7, but Qualcomm will request an extension to patch integration and testing by OEMs.allow more time for patch integration and testing by OEMs.

and for their multiple subsequent requests for an extension and/or grace period.

Your August patches don't fix this - Qualcomm only notified OEMs on 4 August and their plan was to get fixes to OEMs by 7 Sep.

I am fine with this schedule.

Unless someone is actively exploiting devices I would prefer a well tested patch to a rushed patch.

Note that this whole issue is due a previously rushed patch.

It wasn't due to a rushed patch - the patch just gave the Project Zero researcher an idea for where he should look.

There's no real way of being sure if it is being exploited. I guess no exploits had been detected a couple of days ago, but it's not uncommon for the way it gets detected it for someone to find the exploit software somewhere. That's how Project Zero found these iOS issues for example[1].

[1] https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...

For comparison, Google Chrome tries to get security patches to most users within 24 hours.

Yet most android devices are lucky to receive a patch within a few months... Don't worry though - that's only a window of a few months where an evil actor can drain your bank account and log your porn browsing sessions...

As someone using iOS, does Chrome really update multiple times a week for security patches? Am I overestimating how often security fixes go in?

Critical security issues 'in the wild' only come up once every few months, but yes, when they do, the Chrome team has someone on duty 24 hours per day whose responsibility is to patch the code and do a release to all users within a matter of hours.

If you submit a security issue to Chrome, they actually have a tickbox on the webform to say "this issue is important enough to get someone out of bed for", and if you tick that box, it will actually wake someone at 3am to deal with it...

You should probably wait for an example where Google didn't put off writing the issue up for a year after the initial report.

What does this mean? They (Project Zero) only started working on this in June 2020 (" However in June 2020, I noticed that the patch for CVE-2019-10567 was incomplete, and worked with Qualcomm's security team and GPU engineers to fix the issue at its root cause.... It's our understanding that Qualcomm will list this publicly in their November 2020 bulletin.")

Reply on news.ycombinator.com