On 10/25/2018 03:50 PM, Jan Beulich wrote: >>>> On 22.10.18 at 16:55, <wei.l...@citrix.com> 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? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
