Re: SpectreV1+L1TF Patch Series

[Andrew Cooper <andrew.cooper3@citrix.com>]

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.


Next, to the ordering of patches.

Please introduce the Kconfig variable(s) first.  I'll follow up on that
thread about options.

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.

Next, introduce eval_nospec().  To avoid interfering with other
architectures, you probably want something like 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.

~Andrew

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