Re: [patch V4 05/11] x86/speculation/mds: Clear CPU buffers on exit to user

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, 26 Feb 2019, speck for Josh Poimboeuf wrote:
> On Fri, Feb 22, 2019 at 11:24:23PM +0100, speck for Thomas Gleixner wrote:
> > +1. Return to user space
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +   When transitioning from kernel to user space the CPU buffers are flushed
> > +   on affected CPUs:
> > +
> > +   - always when the mitigation mode is full. The migitation is enabled
> 
> Currently the mitigation is always full.
> 
> > +     through the static key mds_user_clear.
> > +
> > +   This covers transitions from kernel to user space through a return to
> > +   user space from a syscall and from an interrupt or a regular exception.
> > +
> > +   There are other kernel to user space transitions which are not covered
> > +   by this: NMIs and all non maskable exceptions which go through the
> > +   paranoid exit, which means that they are not invoking the regular
> 
> Actually, NMI *is* mitigated.

But not by the above. That's a separate mitigation point due to the mess
which the x86 exception handling is.

> What is a non maskable exception?

All exceptions which are delivered despite interrupts being disabled, NMI,
MCE, DF, ....

> The statement about all paranoid exits being covered isn't correct,
> because #DF is mitigated.
> 
> > +   prepare_exit_to_usermode() which handles the CPU buffer clearing.
> > +
> > +   Access to sensible data like keys, credentials in the NMI context is
> > +   mostly theoretical: The CPU can do prefetching or execute a
> > +   misspeculated code path and thereby fetching data which might end up
> > +   leaking through a buffer.
> 
> This paragraph can be removed, since NMI is mitigated.
> 
> > +
> > +   But for mounting other attacks the kernel stack address of the task is
> > +   already valuable information. So in full mitigation mode, the NMI is
> > +   mitigated on the return from do_nmi() to provide almost complete
> > +   coverage.
> 
> This one is correct.
> 
> > +
> > +   There is one non maskable exception which returns through paranoid exit
> 
> Again the phrase "non maskable exception".  Maybe I'm missing something
> but I have no idea what that means.
>
> > +   and is to some extent controllable from user space through
> > +   modify_ldt(2): #DF. So mitigation is required in the double fault
> > +   handler as well.
> > +
> > +   Another corner case is a #MC which hits between the buffer clear and the
> > +   actual return to user. As this still is in kernel space it takes the
> > +   paranoid exit path which does not clear the CPU buffers. So the #MC
> > +   handler repopulates the buffers to some extent. Machine checks are not
> > +   reliably controllable and the window is extremly small so mitigation
> > +   would just tick a checkbox that this theoretical corner case is covered.
> 
> There is no mention of #DB anywhere, shouldn't it also be mitigated?

If #DB comes from a user space int1 then it will go through the regular
return to user path which is mitigated. If it happens in the kernel, it's
not relevant.

The thing about NMI and the #DF special case is that even if they come from
user space they are not returning through the regular path and therefore
need explicit mitigation.

I'll reword the whole thing so it's less confusing.

Thanks,

	tglx