[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.