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. From a practical point of view, until people work out how to comprehensively solve SP1, reducing the quantity of mapped data is the only practical defence that an OS/Hypervisor has. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
