On 31/01/2019 16:54, Jan Beulich wrote: >>>> On 31.01.19 at 17:35, <andrew.coop...@citrix.com> wrote: >> On 31/01/2019 14:25, Jan Beulich wrote: >>>>>> On 31.01.19 at 14:59, <andrew.coop...@citrix.com> wrote: >>>> At the time XSA-273 was published, shadowing dom0 had proved to be >>>> unstable, >>>> which is why dom0 was unprotected by default. The instability was >> identified >>>> to be problems with shadowing PV superpages, and fixed. >>>> >>>> In hindsight, this patch should have been posted at the same time. >>>> >>>> There is now no legitimate reason to handle dom0 differently to domu when >>>> it >>>> comes to pv-l1tf protections. >>> I'm not entirely convinced by this statement: Crashing Dom0 >>> (and hence the entire host) because of a failure to enable >>> shadow mode on it is not a good thing imo. What's wrong >>> with sticking to the current default, just for reasons other >>> than the original one? Anything malicious running in Dom0 >>> has easier (or at least different) ways of getting at the same >>> information. >> This statement is only true of the dom0 kernel (and root userspace, >> given the questionable behaviour of /proc/xen/privcmd). >> >> It does not hold for regular dom0 userspace - in particular, L1TF was >> discovered because of an accidental mprotect(PROT_NONE), meaning that >> this is a viable attack vector for a depriv qemu. > But that's an attack against its kernel, isn't it? That is, and updated > Dom0 kernel would already guard against issues.
L1TF is always against attacker-controlled MFN's, even when the attacker is in an HVM domain. PV-L1TF mitigations protect from any attack inside the guest, at the cost of guest performance if the kernel is out of date and not mitigating the userspace attack itself. >> As to crashing, that is only if you compile SHADOW out, and I remain to >> be convinced that compiling shadow out of Xen is a viable option at the >> moment. > Or simply running out of memory. Shadows get recycled. > >> Basically, if you've got an updated dom0 kernel, you'll be fine even >> with this default flipped. If you've forgotten/missed that, then you're >> already wide open (in a lack of defence in depth way) and flipping the >> default here will make things blindly obvious. > Well, for new versions flipping the default may indeed be acceptable > based on this argument. But even then - and even more so for stable > versions - the change in behavior may come as a surprise to people > who have perhaps even deliberately chosen not to upgrade their > kernels. If it were not with the instability, XSA-273 would have gone out with this default. That alone is justification for this to be backported. Arguably, we should have reissued XSA-273 after I discovered and fixed the superpage shadowing bugs. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
