[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xen-devel
Subject:    Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default
From:       Andrew Cooper <andrew.cooper3 () citrix ! com>
Date:       2019-01-31 17:19:40
Message-ID: 8e823487-3f3a-fc7e-4ffc-9bda20c3d5da () citrix ! com
[Download RAW message or body]

On 31/01/2019 16:54, Jan Beulich wrote:
>>>> On 31.01.19 at 17:35, <andrew.cooper3@citrix.com> wrote:
>> On 31/01/2019 14:25, Jan Beulich wrote:
>>>>>> On 31.01.19 at 14:59, <andrew.cooper3@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
[prev in list] [next in list] [prev in thread] [next in thread]