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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan



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