Microarchitectural state flush for timing-channel prevention

Gernot <gernot.heiser@...>

Dear Privspec members,

You may recall that I had argued for an operation to flush microarchitectural state in order to allow the OS to prevent timing channels. I believe the need for this was not disputed, but the open question is what is the right abstraction.

I’m not offering an answer to the abstraction question ;-) However, I’d like to share our recent work with the Ariane folks at ETH, where we implemented such a flush and evaluated its effectiveness as well as overhead. The results are extremely encouraging, and written up here: https://arxiv.org/abs/2005.02193.

In a nutshell
- we could show that all channels could be closed
- we learned that you have to be really thorough and invalidate more than just cache-line tags
- we found the overhead negligible (given that a switch of security-domain is happening at no more than a millisecond rate).

The details are somewhat specific to the Ariane, which is a simple, in-order pipeline and presently has a write-through L1D. On a more high-performance design there would be more to flush and the cost would be higher. However, I do not expect this to change the overall picture.


Join tech-privileged@lists.riscv.org to automatically receive all group messages.