If it's in the DSP it may not need to be an app that runs the exploit. Sounds like any malicious audio or video file could do it. Could be something delivered via a streaming site, email, audio embedded in a webpage, etc. This sounds like it could be a very big deal.
It's great that Qualcomm has a fix, but most of the susceptible devices will likely never get it in an update from their manufacturers. And I wonder if there will be a performance or battery life hit like the awful performance hit in the Intel chips. That one cost me a 30% hit on my servers and resulted in 6 figures of unplanned spending to replace that lost capacity.
The fix could also be nothing more than just disable the DSP, a specific functionality or in some other means limit it considerably (for example disabling or heavily restricting its DMA).
So a fix might not be a fix for all, if this bug is in some obscure codec or some extreme edge case that no one uses the fix might be painless, Google might even find a way to soft patch it via GPS but if it’s not then you might have devices either losing key functionality or becoming vulnerable to a pretty severe exploit.
Another question of exploitation is how much hand crafting is required for the payload and does the payload survive common encoders as most social media platforms re-encode or transcode media that is uploaded or shared through their platform even WhatsApp and other messaging apps do it by default (tho those do it to save bandwidth).
If the exploit payload survives common encoders which are used by social media platforms it would be quite a disaster once people understand how it works and can be exploited.
The patch itself also might be bypassable Apple for example fixed an exploit using SEPROM and shortly after that exploit was working again by bypassing the SEPROM boot.
> If it's in the DSP it may not need to be an app that runs the exploit. Sounds like any malicious audio or video file could do it. Could be something delivered via a streaming site, email, audio embedded in a webpage, etc. This sounds like it could be a very big deal.
Seems unlikely to me. DSP data vs DSP code - I think it's in the latter that you'll find vulnerabilities.
It’s not about pay. People that don’t sleep make mistakes - no matter what you pay them. Rest is an essential part of performance. Some people may need more and others less, but there’s no one that doesn’t.
No need to take it so literally. I read "No one sleeps until this is fixed" as "This is the top priority, push everything else aside. Do not screw around, stay late if you can. Everyone who can work on this needs to fix it."
I doubt 2020 Google employees have the same level of drive that the NASA employees of Apollo 13 era had. I doubt NASA employees said "I give them what they give me, 40 hours." Employees now a days show up to collect a pay check just long enough so the job looks good on their resumé for the next job.
Could Google theoretically remotely disable/remove apps that they identify using the DSP in malicious ways?