>>> On 27.02.19 at 17:13, <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>
Acked-by: Jan Beulich <jbeul...@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
