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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/01/2019 11:51, Norbert Manthey wrote:
> This commit introduces the configuration option L1TF_LFENCE that allows
> to control the implementation of the protection of privilege checks via
> lfence instructions. The following four alternatives are provided:
>
>  - not injecting lfence instructions
>  - inject an lfence instruction for both outcomes of the conditional
>  - inject an lfence instruction only if the conditional would evaluate
>    to true, so that this case cannot be entered under speculation
>  - evaluating the condition and store the result into a local variable.
>    before using this value, inject an lfence instruction.

Can we take a step back and think about what is going on here.

TBH, I'm dubious of the overall utility of this option.  Either people
value their security and disabled HT for L1TF, or they opted for
performance instead.  However, I accept that there are plenty of people
who are playing fast and loose with that perhaps this series in an
intermediate they'd choose.

That is not to say I agree with the reasoning which lead to that choice,
but that having such an option available in some form in Xen is likely
to be useful to some people.

So, getting to the people playing fast and loose with their security... 
They will be wanting this to gain some security, at a perf expense which
they expect to be far less than disabling HT.


In practice, you generally only need a fence for one of the two basic
blocks following a conditional, but because we are not the compiler, we
cannot evaluate which side is safe at compile time, especially as the
compiler is able to optimise sub expressions.

Therefore, the "fence on true" or "fence on false" options are fairly
useless.  On average, they will "fix" 50% of the conditional branches,
but you won't know which until you disassemble the resulting binary.

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.

The only one of these options I see which has any value is the fence on
both sides of the condition, because it is the only one which
meaningfully improves the security of the resulting binary.

~Andrew

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