Re: [RFC PATCH] arch/x86: Optionally flush L1D on context switch

["Singh, Balbir" <sblbir@amazon.com>]

On Sun, 2020-03-22 at 08:10 -0700, Andy Lutomirski wrote:
> 
> > I still think flushing the "high value" process L1D on switch_mm out is
> > the way to go here...
> 
> Let me try to understand the issue. There is some high-value data, and that
> data is owned by a high-value process. At some point, the data ends up in
> L1D.  Later in, evil code runs and may attempt to exfiltrate  that data from
> L1D using a side channel. (The evil code is not necessarily in a malicious
> process context. It could be kernel code targeted by LVI or similar. It
> could be ordinary code that happens to contain a side channel gadget by
> accident.)
> 
> So the idea is to flush L1D after manipulating high-value data and before
> running evil code.
> 
> The nasty part here is that we don’t have a good handle on when L1D is
> filled and when the evil code runs. If the evil code is untrusted process
> userspace and the fill is an interrupt, then switch_mm is useless and we
> want to flush on kernel exit instead. If the fill and evil code are both
> userspace, then switch_mm is probably the right choice, but
> prepare_exit_from_usermode works too. If SMT is on, we lose no matter
> what.  If the evil code is in kernel context, then it’s not clear what to
> do. If the fill and the evil code are both in kernel threads (hi, io_uring),
> then I’m not at all sure what to do.
> 
> In summary, kernel exit seems stronger, but the right answer isn’t so clear.
> 
> We could do an optimized variant where we flush at kernel exit but we
> *decide* to flush in switch_mm.

I think the key question in the LVI case would be, is it possible to do an LVI
in a kernel context? If the answer is no, switch_mm() is sufficient, but for
now these patches focus on flushing L1D on task exit, we could add the use
case for LVI (which is called out)

Balbir Singh.