Re: [Xen-devel] SpectreV1+L1TF Patch Series

[Norbert Manthey <nmanthey@xxxxxxxxx>]

On 1/24/19 22:05, Andrew Cooper wrote:
> On 23/01/2019 11:51, Norbert Manthey wrote:
>> Dear all,
>>
>> This patch series attempts to mitigate the issue that have been raised in the
>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
>> execution on Intel hardware, an lfence instruction is required to make sure
>> that selected checks are not bypassed. Speculative out-of-bound accesses can
>> be prevented by using the array_index_nospec macro.
>>
>> The lfence instruction should be added on x86 platforms only. To not affect
>> platforms that are not affected by the L1TF vulnerability, the lfence
>> instruction is patched in via alternative patching on Intel CPUs only.
>> Furthermore, the compile time configuration allows to choose how to protect 
>> the
>> evaluation of conditions with the lfence instruction.
> Hello,
>
> First of all, I've dusted off an old patch of mine and made it
> speculatively safe.
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=9e92acf1b752dfdfb294234b32d1fa9f55bfdc0f
>
> Using the new domain_vcpu() helper should tidy up quite a few patches in
> the series.
I will use the introduced function and apply it where I touched code,
thanks!
>
>
> Next, to the ordering of patches.
>
> Please introduce the Kconfig variable(s) first.  I'll follow up on that
> thread about options.
I will drop the Kconfig option and go with "protect both branches" only.
>
> Next, introduce a new synthetic feature bit to cause patching to occur,
> and logic to trigger it in appropriate circumstances.  Look through the
> history of include/asm-x86/cpufeatures.h to see some examples from the
> previous speculative mitigation work.  In particular, you'll need a
> command line parameter to control the use of this functionality when it
> is compiled in.
I will introduce a synthesized feature, and a command line option, and
add documentation.
>
> Next, introduce eval_nospec().  To avoid interfering with other
> architectures, you probably want something like this:
Do you want me to introduce the new macro in a separate commit, and use
it in follow up commits? I have been told previously to not split
introduced functions from their use cases, but merge them with at least
one. Your above commit again only introduces an at this point unused
function. Is there a Xen specifc style rule for this?
> xen/nospec.h contains:
>
> /*
>  * Evaluate a condition in a speculation-safe way.
>  * Stub implementation for builds which don't care.
>  */
> #ifndef eval_nospec
> #define eval_nospec(x) (x)
> #endif
>
> and something containing x86's implementation.  TBH, I personally think
> asm/nospec.h is overdue for introducing now.

For now, I would like to not introduce new files, as Jan also suggested
earlier.

Best,
Norbert

>
> ~Andrew




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