[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.