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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
