Controlling access to the memory cache

Posted Jul 21, 2016 6:09 UTC (Thu) by roc (subscriber, #30627)
Parent article: Controlling access to the memory cache

To me the most important thing about this hardware feature is that it could be used to block cache-snooping attacks launched by untrusted code, e.g. http://arxiv.org/pdf/1502.07373v2.pdf. I guess this interface can be used to do that --- reserving cache slices for untrusted code by removing them from the root 'schemas' file and assigning them to some specific low-trust tasks via a subdirectory.

It would be nice to also be able to flush specific slices on a context switch to insulate different low-trust tasks from each other.

Controlling access to the memory cache

Posted Jul 26, 2016 13:29 UTC (Tue) by JanC_ (guest, #34940) [Link] (1 responses)

Wouldn't you also need CAT support on L1 & L2 caches for that?

Controlling access to the memory cache

Posted Jul 26, 2016 15:15 UTC (Tue) by excors (subscriber, #95769) [Link]

And probably the TLBs too - I don't see why the cache attacks couldn't be adapted to run on them (albeit with 4KB resolution rather than 64B, and I think TLBs aren't shared between cores so it could only spy on other threads if they were running on the same core with hyperthreading).

Incidentally, rather than relying on JS, I wonder if you could do these L3 cache attacks using WebGL, given that Intel GPUs share the CPU's L3/LLC? I think it might be relatively straightforward if they supported GLES 3.1 functionality - write a compute shader that runs N threads each looping over 1/N of a cache-sized buffer (with large N to maximise bandwidth utilisation and improve the attack's temporal resolution), and measure the latency of each access by reading a global counter that's atomically incremented in a tight loop by another thread. Not sure if it's possible to do something equivalent with GLES 2.0/3.0 features though, since I can't see how to measure latency in them.