[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.