[Xen-devel] SpectreV1+L1TF Patch Series
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. Best, Norbert 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] SpectreV1+L1TF Patch Series v7
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), namely to avoid touching memory from the hypervisor speculatively that would not be touched without speculation. 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 major changes between v6 and v7 of this series are preferring the lfence instruction to block speculation over updating variables. Furthermore, when patching in the lfence instruction automatically, the setting of smt and l1d flushing are taken into account. Best, Norbert 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] SpectreV1+L1TF Patch Series
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
Re: [Xen-devel] SpectreV1+L1TF Patch Series
Jürgen, >>> On 23.01.19 at 12:51, wrote: > 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. I've noticed only now that you weren't Cc-ed on this series. It clearly is something to at least be considered for 4.12. May I ask what your view on this is? Perhaps in particular whether you would want to set some boundary in time until which pieces of it (as they become ready, which looks to be the case for patches 10 and 11 at this point in time) may go in? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] SpectreV1+L1TF Patch Series
On 28/01/2019 09:28, Jan Beulich wrote: > Jürgen, > On 23.01.19 at 12:51, wrote: >> 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. > > I've noticed only now that you weren't Cc-ed on this series. It > clearly is something to at least be considered for 4.12. May I > ask what your view on this is? Perhaps in particular whether > you would want to set some boundary in time until which pieces > of it (as they become ready, which looks to be the case for > patches 10 and 11 at this point in time) may go in? I'd say until RC3 they are fine to go in when ready. After that I'd like to decide on a case-by-case basis. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] SpectreV1+L1TF Patch Series
>>> On 28.01.19 at 09:47, wrote: > On 28/01/2019 09:28, Jan Beulich wrote: > On 23.01.19 at 12:51, wrote: >>> 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. >> >> I've noticed only now that you weren't Cc-ed on this series. It >> clearly is something to at least be considered for 4.12. May I >> ask what your view on this is? Perhaps in particular whether >> you would want to set some boundary in time until which pieces >> of it (as they become ready, which looks to be the case for >> patches 10 and 11 at this point in time) may go in? > > I'd say until RC3 they are fine to go in when ready. After that I'd like > to decide on a case-by-case basis. May I interpret this as a release ack for patches 10 and 11 of v4 then, and perhaps even generally as such an ack for other parts of the series (with the RC3 boundary in mind)? Jan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] SpectreV1+L1TF Patch Series
On 28/01/2019 10:56, Jan Beulich wrote: On 28.01.19 at 09:47, wrote: >> On 28/01/2019 09:28, Jan Beulich wrote: >> On 23.01.19 at 12:51, wrote: 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. >>> >>> I've noticed only now that you weren't Cc-ed on this series. It >>> clearly is something to at least be considered for 4.12. May I >>> ask what your view on this is? Perhaps in particular whether >>> you would want to set some boundary in time until which pieces >>> of it (as they become ready, which looks to be the case for >>> patches 10 and 11 at this point in time) may go in? >> >> I'd say until RC3 they are fine to go in when ready. After that I'd like >> to decide on a case-by-case basis. > > May I interpret this as a release ack for patches 10 and 11 of > v4 then, and perhaps even generally as such an ack for other > parts of the series (with the RC3 boundary in mind)? Yes. Juergen ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] SpectreV1+L1TF Patch Series
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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] SpectreV1+L1TF Patch Series v5
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 L1TF vulnerable CPUs only. To control the patching mechanism, I introduced a command line option and a synthesized CPU feature flag. Best, Norbert 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] SpectreV1+L1TF Patch Series v6
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 major changes between v5 and v6 of this series are the introduction of asm specific nospec.h files that introduce macros to add lfence instructions to conditionals to be evaluated. Furthermore, updating variable that might not be located in a register is tried to be avoided. Best, Norbert 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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] SpectreV1+L1TF Patch Series v6
Hi, Please don't send the next version in reply-to a random e-mail from the previous version. Instead you should create a new thread to make things easier for review. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
