[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Ongoing/future speculative mitigation work
>>> 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 (and hence could spy at xenheap but - due to not being mapped - not domheap)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |