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. 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. 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
