Re: [PATCH 2/2] x86/retpoline: Fix return buffer filling

[David Woodhouse <dwmw2@infradead.org>]

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

On Mon, 2018-02-12 at 16:04 -0800, Andi Kleen wrote:
> From: Andi Kleen <ak@linux.intel.com>
> 
> An earlier patch moved the RSB filling out of line, ending
> it with a return. This results in the return buffer filling
> only giving 15 instead of 16 usable returns because
> the return from fill_rsb already uses one up.
> 
> Since the kernel call chains can be quite deep that's
> somewhat dangerous and better avoided.

This only matters for Skylake, right? In conjunction with the call
depth counting stuff that Ingo and Thomas looked at and seem to have
given up on?

On non-Skylake we don't care about underflow, and all that matters is
that we get rid of any *bogus* entries in the RSB? 

However... that was supposed to be a 'clear RSB' operation, with 32
CALLs in sequence. And Boris changed it to 16 by calling __fill_rsb()
instead of __clear_rsb():

-       asm volatile (ANNOTATE_NOSPEC_ALTERNATIVE
-                     ALTERNATIVE("jmp 910f",
-                                 __stringify(__FILL_RETURN_BUFFER(%0, RSB_CLEAR_LOOPS, %1)),
-                                 X86_FEATURE_RETPOLINE)
-                     "910:"
-                     : "=r" (loops), ASM_CALL_CONSTRAINT
-                     : : "memory" );
+       alternative_input("",
+                         "call __fill_rsb",
+                         X86_FEATURE_RETPOLINE,
+                         ASM_NO_INPUT_CLOBBER(_ASM_BX, "memory"));

I think we do need to revert that patch. And perhaps stop accepting any
more similar bikeshedding.

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