[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default
>>> On 31.01.19 at 17:35, <andrew.cooper3@xxxxxxxxxx> wrote: > On 31/01/2019 14:25, Jan Beulich wrote: >>>>> On 31.01.19 at 14:59, <andrew.cooper3@xxxxxxxxxx> 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. > 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. > 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |