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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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@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.

Correct.  All of these suggestions are for increased defence in depth. 
They are not replacements for the existing mitigations.

From a practical point of view, until people work out how to
comprehensively solve SP1, reducing the quantity of mapped data is the
only practical defence that an OS/Hypervisor has.

~Andrew

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