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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

Everything which is virtually mapped in Xen is potentially vulnerable,
and the goal of the "secret-free Xen" is to make sure that in the
context of one vcpu pulling off an attack like this, there is no
interesting data which can be exfiltrated.

A single xenheap model means that everything allocated with
alloc_xenheap_page() (e.g. struct domain, struct vcpu, pcpu stacks) are
potentially exposed to all domains.

A split xenheap model means that data pertaining to other guests isn't
mapped in the context of this vcpu, so cannot be brought into the cache.

~Andrew

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