Re: Ongoing/future speculative mitigation work

[George Dunlap <george.dunlap@citrix.com>]

On 10/25/2018 05:50 PM, Andrew Cooper wrote:
> On 25/10/18 17:43, George Dunlap wrote:
>> 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@citrix.com> wrote:
>>>>> On 10/25/2018 03:50 PM, Jan Beulich wrote:
>>>>>>>>> On 22.10.18 at 16:55, <wei.liu2@citrix.com> 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.
> 
> Correct.  All of these suggestions are for increased defence in depth. 
> They are not replacements for the existing mitigations.

But it could be a mitigation for, say, Meltdown, yes?  I'm trying to
remember the details; but wouldn't a "secret-free Xen" mean that
disabling XPTI entirely for 64-bit PV guests would be a reasonable
decision (even if many people left it enabled 'just in case')?

 -George

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