[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH L1TF v10 2/8] nospec: introduce evaluate_nospec
>>> On 14.03.19 at 13:50, <nmanthey@xxxxxxxxx> 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 <nmanthey@xxxxxxxxx> > Acked-by: Julien Grall <julien.grall@xxxxxxx> I did give my ack on v9, and I see no indication of changes which may have invalidated it. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |