Re: [Xen-devel] [PATCH SpectreV1+L1TF v4 03/11] config: introduce L1TF_LFENCE option

[Norbert Manthey <nmanthey@xxxxxxxxx>]

On 1/25/19 14:09, Jan Beulich wrote:
>>>> On 25.01.19 at 11:50, <nmanthey@xxxxxxxxx> wrote:
>> On 1/25/19 11:14, Jan Beulich wrote:
>>>>>> On 24.01.19 at 22:29, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> Worse is the "evaluate condition, stash result, fence, use variable"
>>>> option, which is almost completely useless.  If you work out the
>>>> resulting instruction stream, you'll have a conditional expression
>>>> calculated down into a register, then a fence, then a test register and
>>>> conditional jump into one of two basic blocks.  This takes the perf hit,
>>>> and doesn't protect either of the basic blocks for speculative
>>>> mis-execution.
>>> How does it not protect anything? It shrinks the speculation window
>>> to just the register test and conditional branch, which ought to be
>>> far smaller than that behind a memory access which fails to hit any
>>> of the caches (and perhaps even any of the TLBs). This is the more
>>> that LFENCE does specifically not prevent insn fetching from
>>> continuing.
>>>
>>> That said I agree that the LFENCE would better sit between the
>>> register test and the conditional branch, but as we've said so many
>>> times before - this can't be achieved without compiler support. It's
>>> said enough that the default "cc" clobber of asm()-s on x86 alone
>>> prevents this from possibly working, while my over four year old
>>> patch to add a means to avoid this has not seen sufficient
>>> comments to get it into some hopefully acceptable shape, but also
>>> has not been approved as is.
>>>
>>> Then again, following an earlier reply of mine on another sub-
>>> thread, nothing really prevents the compiler from moving ahead
>>> and folding the two LFENCEs of the "both branches" model into
>>> one. It just so happens that apparently right now this never
>>> occurs (assuming Norbert has done full generated code analysis
>>> to confirm the intended placement).
>> I am happy to jump back to my earlier version without a configuration
>> option to protect both branches with a lfence instruction, using logic
>> operators.
> I don't understand this, I'm afraid: What I've said was to support
> my thinking of the && + || variant being identical in code and risk
> to that using ?: . I.e. I'm not asking you to switch back.

I understand that you did not ask. However, Andrew raised concerns, and
I analyzed the binary output for the variant with logical operators.
Hence, I'd like to keep that variant with the logical operators.

Best,
Norbert

>
> Jan
>
>



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel