On 10/25/2018 05:50 PM, Andrew Cooper wrote: > On 25/10/18 17:43, George Dunlap wrote: >> On 10/25/2018 05:29 PM, Andrew Cooper wrote: >>> On 25/10/18 16:02, Jan Beulich wrote: >>>>>>> On 25.10.18 at 16:56, <george.dun...@citrix.com> wrote: >>>>> 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? >>>> 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. >> Right -- so a split xen/domheap model doesn't prevent L1TF attacks, but >> it does make L1TF much harder to pull off, because it now only works if >> you can manage to get onto the same core as the victim, after the victim >> has accessed the data you want. >> >> So it would reduce the risk of L1TF significantly, but not enough (I >> think) that we could recommend disabling other mitigations. > > Correct. All of these suggestions are for increased defence in depth. > They are not replacements for the existing mitigations.
But it could be a mitigation for, say, Meltdown, yes? I'm trying to remember the details; but wouldn't a "secret-free Xen" mean that disabling XPTI entirely for 64-bit PV guests would be a reasonable decision (even if many people left it enabled 'just in case')? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
