Separate privileges, separate caches

Posted Jan 4, 2018 9:07 UTC (Thu) by epa (subscriber, #39769)
Parent article: Notes from the Intelpocalypse

Since cache timing will always be visible to code (unless you mandate a restricted programming language that cannot precisely measure its own time taken) the only way to fix this in general is to have separate caches for each separate privilege level. As a minimum one for kernel mode and one for user mode. As a small improvement, kernel mode could read the userspace cache (but not write to it) while userspace would have no access to the kernel cache at all.

Since CPUs don't currently support this, the way to emulate it is to flush the cache on each context switch from kernel to user space. This would slow things down. It might require rewriting some kernel APIs to be 'fatter' so that a single call does more work before returning, and you don't need as many context switches.

Separate privileges, separate caches

Posted Jan 4, 2018 11:28 UTC (Thu) by excors (subscriber, #95769) [Link] (2 responses)

These attacks are using the cache as a side channel to leak data from the speculatively-executed instructions to the non-speculative world, but I don't think that's the only possible side channel. E.g. maybe you could use a variable-speed instruction like division ("1 / (v & 1)" etc) and use another hyperthread to measure how long the execution unit is busy for. Or maybe you could use a constant-speed expensive SIMD instruction where certain input values cause lots of transistors to flip between 0s and 1s repeatedly, generating more heat, so you run it in a loop then measure the temperature of the CPU core. (Maybe that one is less plausible). The cache is completely irrelevant in those cases, so you can't fix it by changing the cache design.

Separate privileges, separate caches

Posted Jan 4, 2018 16:06 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Wasn't there already a known information leak with hyperthreading, leading the OpenBSD developers to recommend that you disable it?

Perhaps the cache is not the only thing that lets you snoop but it is certainly a major one.

Separate privileges, separate caches

Posted Jan 4, 2018 21:45 UTC (Thu) by emaste (guest, #121005) [Link]

You may be thinking of the hyperthreading cache side-channel reported by Colin Percival, with a mitigation first in FreeBSD back in 2005. Those details are at http://www.daemonology.net/hyperthreading-considered-harm..., and the paper is at http://www.daemonology.net/papers/htt.pdf.