|
|
|
|
|
|
by mtanski
3092 days ago
|
|
|
I'm thinking you might be right. It's going to be really hard to give up real world gains from branch prediction. Branch prediction can make a lot of real world (read "not the finest code in the world") run at reasonable speeds. Another common pattern to give up would be eliding (branch predicting away) nil reference checks. > short of entirely preventing speculating code from being able to load things into the cache Some new server processors allow us to partition cache (to prevent noisy neighbors) [1,2]. I don't have experience working with this technology but everything I read makes me believe this mechanism can works on a per process basis. If that kind of complexity is already possible in CPU cache hierarchy I wonder if it's possible to implement per process cache encryption. New processors (EPYC) can already use different encryption keys for each VM, so it might be a matter of time till this is extended further. [1] https://danluu.com/intel-cat/ [2] https://lwn.net/Articles/694800/ |
|
|
It's possible to key the cache in the kernel on CPL so at least there should be no user / kernel space scooping of cache lines.
It's possible we can never fully prevent all attacks in same address space. So certain types of applications (JIT and sandboxes) might forever be a cat and mouse game since we're unlikely to give up on branch prediction.