Re: [Xen-devel] [PATCH] x86/pv: Enable pv-l1tf mitigations for dom0 by default

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.01.19 at 18:19, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 31/01/2019 16:54, Jan Beulich wrote:
>>>>> 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.
> 
> L1TF is always against attacker-controlled MFN's, even when the attacker
> is in an HVM domain.

Right, but this doesn't address the point I'm making: If the
Dom0 kernel is up to date, no attack ought to be possible.
And if it's not up to date, the host admin apparently doesn't
care about this particular issue.

> 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.

Sure; I'm talking about running out of memory while enabling
shadow mode.

>>> 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.

I'm not sure this would have been the case - the argument of
avoiding a host crash would still have been one to consider.
I've just checked, and I did bring up that aspect back at the
time already, especially also for the !SHADOW_PAGING case
(where I also continue to think it would be wrong to crash the
host by default), irrespective of whether actually building that
way is a viable option at the moment.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel