On 3/14/19 14:19, Jan Beulich wrote: >>>> On 14.03.19 at 13:50, <nmant...@amazon.de> wrote: >> Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into >> L1 cache is problematic, because when hyperthreading is used as well, a >> guest running on the sibling core can leak this potentially secret data. >> >> To prevent these speculative accesses, we block speculation after >> accessing the domain property field by adding lfence instructions. This >> way, the CPU continues executing and loading data only once the condition >> is actually evaluated. >> >> As this protection is typically used in if statements, the lfence has to >> come in a compatible way. Therefore, a function that returns true after an >> lfence instruction is introduced. To protect both branches after a >> conditional, an lfence instruction has to be added for the two branches. >> To be able to block speculation after several evaluations, the generic >> barrier macro block_speculation is also introduced. >> >> As the L1TF vulnerability is only present on the x86 architecture, there is >> no need to add protection for other architectures. Hence, the introduced >> functions are defined but empty. >> >> On the x86 architecture, by default, the lfence instruction is not present >> either. Only when a L1TF vulnerable platform is detected, the lfence >> instruction is patched in via alternative patching. Similarly, PV guests >> are protected wrt L1TF by default, so that the protection is furthermore >> disabled in case HVM is exclueded via the build configuration. >> >> Introducing the lfence instructions catches a lot of potential leaks with >> a simple unintrusive code change. During performance testing, we did not >> notice performance effects. >> >> This is part of the speculative hardening effort. >> >> Signed-off-by: Norbert Manthey <nmant...@amazon.de> >> Acked-by: Julien Grall <julien.gr...@arm.com> > I did give my ack on v9, and I see no indication of changes which > may have invalidated it.
That is a miss on my side. Norbert > > Jan > > 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
