If they isolate the memory that each part of the SoC can process, that means large amounts of data (for high definition video) have to be copied from one processor to another, so there's direct access. Then if the DSP's firmware has buffer overrun bugs, craft a suitable video and read/write whatever memory area you want to. (Not sure that this is what the bug is, but it's my guess).
Yes - that’s what iOS devices and modern computers do. The risks of allowing unrestricted DMA started to get publicized in the mid-2000s when FireWire was used to attack locked Macs. IOMMUs are pretty common now but the OS still has to enable them.
IOMMUs aren't the only way to get secure DMA, it's more common for small devices to have a double-ended device where the other end (OS vs. DSP in this case) needs to set up its own pointers itself. Doing it via page mapping is very heavyweight and used for performance reasons when you need both safety AND fast random access to large regions.
Yes - my main reaction was just that it was something of a surprise to see Qualcomm not using any of the common countermeasures for a class of attack which is not new and for which they’ve had problems in the past.
They likely do sandbox it to some extent. It's routine for these devices to have their own SRAM decoupled from main memory, and to have a hardware-managed window to get to OS-visible RAM. Often there's a DMA controller that does that instead, etc...
But all sandboxes can have holes. The phrasing in the article actually makes it sound more like this is a software bug in the firmware and not a hardware thing per se.
GPUs likewise have a somewhat cooked visibility to DRAM and some amount of mapping and hardware DMA intermediate interfaces. But sure, a similar GPU flaw could do the same thing.
Wouldn't it make sense for Qualcomm to hardware/software sandbox the memory content being processed by each part of the SoC?
Would such an attack also work on PCs with iGPUs, since they share the system memory?