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

[Jan Beulich <JBeulich@xxxxxxxx>]

On 03.07.2019 13:37, Andrew Cooper wrote:
> On 01/02/2019 07:39, Jan Beulich wrote:
>>>>> 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.
> 
> I know what you said at the time, and perhaps it ought to be telling
> that you didn't change my mind.
> 
> It is frankly exhausting having this argument repeatedly, but my
> position is not changing.

I could be saying the same, and there we'd be in another dead end.

> To be absolutely clear, I would have gone as far as nacking an attempt
> to make it not the default, had it not been for the instability we
> ultimately failed to fix within the embargo window.
> 
> About ~100% of deployments which are going to take this change will have
> a fixed dom0 kernel, so this is a no-op in terms of behaviour.

I don't buy this argument, seeing how especially large customers
are rather slow in applying updates to their systems. I say this in
particular because in principle this change is a candidate for
backporting (which prior discussion shows we're in agreement on),
yet then it wouldn't be just new installations or properly upgraded
ones that might get the change in behavior. One could only hope that
together with a hypervisor update people would also put in place any
available Dom0 kernel ones.

I had to deal with people being puzzled about their guests getting
crashed, despite the log clearly saying why. I don't fancy having
to deal with similar host-wide issues.

> However, we really do have production downstream users where dom0
> doesn't have carte blanch access to guest memory, and therefore the "is
> all powerful" argument is false.  For those deployments, the current
> default is a security risk.
> 
> Dom0 is not sufficiently special that the pv-l1tf default warrants being
> the odd-feature-out.

I'm willing to ack this (on the basis that this is overridable via
command line option), provided we can settle on one of the aspects
I've mentioned before (which may require changes elsewhere then):

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

I don't see how recycling helps at the point where we want to enable
shadow mode on Dom0. Yet I continue to think that such a condition
(in particular because it's not something anyone would predict could
happen at a particular point in time) should explicitly not be fatal
to a host.

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