4 ms·

Money quote from the abstract: "Compression induces data-dependent DRAM traffic and cache utilization, which can be measured through side-channel analysis." Th

Money quote from the abstract: "Compression induces data-dependent DRAM traffic and cache utilization, which can be measured through side-channel analysis." This attack vector doesn't seem to be very GPU-specific. Maybe the memory access pattern and the compression used by the GPU drivers combined with the sensitivity of the information being transferred make the GPU drivers an attractive target for this attack vector. But in principle this attack vector could be present for other processes without the GPU being involved at all, couldn't it? CPU cache is a big side-channel across processes ran on the CPU.

kimixa 3y ago
Unless the traffic has some correlation to the contents - e.g. the data is compressed so "simpler" data has less traffic - it doesn't seem directly relevant. As far as I'm aware, there's no data dependance on CPU cache or dram busses with one exception - zeroing cache lines are often special-cased. This might be useful for some very specific attacks? Also this might be usable as an attack on an OS that use some sort of compressed ram or swap - evicting a page from a target process's working set could cause something that could be measured, and thus information about how well the compression algorithm it uses happened to cope, telling you something about the contents. But one of the big parts of this is the iframe transforms allowing you to amplify the "interesting" data from the noise across security boundaries (IE turning a single pixel into a large number of compressed tiles, making the attack much simpler). That feels like more of a software issue than a hardware one. I'm not sure if something similar can be done on the CPU side of things, and if that's strictly required to make this attack possible, or just easier.