Re: [PATCH L1TF v10 2/8] nospec: introduce evaluate_nospec

From: Norbert Manthey <nmanthey@amazon.de>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <jgross@suse.com>, Tim Deegan <tim@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Dario Faggioli <dfaggioli@suse.com>,
	Martin Pohlack <mpohlack@amazon.de>,
	wipawel@amazon.de, Julien Grall <julien.grall@arm.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	"Martin Mazein(amazein)" <amazein@amazon.de>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Bjoern Doebel <doebel@amazon.de>
Subject: Re: [PATCH L1TF v10 2/8] nospec: introduce evaluate_nospec
Date: Thu, 14 Mar 2019 14:21:55 +0100	[thread overview]
Message-ID: <8ad4d1a8-cd32-dbc9-e21f-234ec25dcaa1@amazon.de> (raw)
In-Reply-To: <5C8A54DD020000780021E9DC@prv1-mh.provo.novell.com>

On 3/14/19 14:19, Jan Beulich wrote:
>>>> On 14.03.19 at 13:50, <nmanthey@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 <nmanthey@amazon.de>
>> Acked-by: Julien Grall <julien.grall@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