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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 24.01.19 at 22:29, <andrew.cooper3@citrix.com> 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).

Jan



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