Re: [Xen-devel] Ongoing/future speculative mitigation work

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 10/25/2018 05:29 PM, Andrew Cooper wrote:
> On 25/10/18 16:02, Jan Beulich wrote:
>>>>> On 25.10.18 at 16:56, <george.dunlap@xxxxxxxxxx> wrote:
>>> On 10/25/2018 03:50 PM, Jan Beulich wrote:
>>>>>>> On 22.10.18 at 16:55, <wei.liu2@xxxxxxxxxx> wrote:
>>>>> On Thu, Oct 18, 2018 at 06:46:22PM +0100, Andrew Cooper wrote:
>>>>>> An easy first step here is to remove Xen's directmap, which will mean
>>>>>> that guests general RAM isn't mapped by default into Xen's address
>>>>>> space.  This will come with some performance hit, as the
>>>>>> map_domain_page() infrastructure will now have to actually
>>>>>> create/destroy mappings, but removing the directmap will cause an
>>>>>> improvement for non-speculative security as well (No possibility of
>>>>>> ret2dir as an exploit technique).
>>>>> I have looked into making the "separate xenheap domheap with partial
>>>>> direct map" mode (see common/page_alloc.c) work but found it not as
>>>>> straight forward as it should've been.
>>>>>
>>>>> Before I spend more time on this, I would like some opinions on if there
>>>>> is other approach which might be more useful than that mode.
>>>> How would such a split heap model help with L1TF, where the
>>>> guest specifies host physical addresses in its vulnerable page
>>>> table entries
>>> I don't think it would.
>>>
>>>> (and hence could spy at xenheap but - due to not
>>>> being mapped - not domheap)?
>>> Er, didn't follow this bit -- if L1TF is related to host physical
>>> addresses, how does having a virtual mapping in Xen affect things in any
>>> way?
>> Hmm, indeed. Scratch that part.
> 
> There seems to be quite a bit of confusion in these replies.
> 
> To exploit L1TF, the data in question has to be present in the L1 cache
> when the attack is performed.
> 
> In practice, an attacker has to arrange for target data to be resident
> in the L1 cache.  One way it can do this when HT is enabled is via a
> cache-load gadget such as the first half of an SP1 attack on the other
> hyperthread.  A different way mechanism is to try and cause Xen to
> speculatively access a piece of data, and have the hardware prefetch
> bring it into the cache.

Right -- so a split xen/domheap model doesn't prevent L1TF attacks, but
it does make L1TF much harder to pull off, because it now only works if
you can manage to get onto the same core as the victim, after the victim
has accessed the data you want.

So it would reduce the risk of L1TF significantly, but not enough (I
think) that we could recommend disabling other mitigations.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel