Re: [PATCH] x86/retpoline: Avoid return buffer underflows on context switch

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Mon, 2018-01-08 at 12:15 -0800, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> [This is on top of David's retpoline branch, as of 08-01 this morning]
> 
> This patch further hardens retpoline
> 
> CPUs have return buffers which store the return address for
> RET to predict function returns. Some CPUs (Skylake, some Broadwells)
> can fall back to indirect branch prediction on return buffer underflow.
> 
> With retpoline we want to avoid uncontrolled indirect branches,
> which could be poisoned by ring 3, so we need to avoid uncontrolled
> return buffer underflows in the kernel.
> 
> This can happen when we're context switching from a shallower to a
> deeper kernel stack.  The deeper kernel stack would eventually underflow
> the return buffer, which again would fall back to the indirect branch predictor.
> 
> To guard against this fill the return buffer with controlled
> content during context switch. This prevents any underflows.
> 
> We always fill the buffer with 30 entries: 32 minus 2 for at
> least one call from entry_{64,32}.S to C code and another into
> the function doing the filling.
> 
> That's pessimistic because we likely did more controlled kernel calls.
> So in principle we could do less.  However it's hard to maintain such an
> invariant, and it may be broken with more aggressive compilers.
> So err on the side of safety and always fill 30.
> 
> Signed-off-by: Andi Kleen <ak@linux.intel.com>

Thanks.

Acked-by: David Woodhouse <dwmw@amazon.co.uk>

We want this on vmexit too, right? And the IBRS/IBPB patch set is going
to want to do similar things. But picking the RSB stuffing out of that
patch set and putting it in with the retpoline support is absolutely
the right thing to do.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]