Re: [PATCH v5 1/4] domctl: introduce a new domain create flag, XEN_DOMCTL_CDF_evtchn_fifo, ...

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 07/12/2020 09:17, Jan Beulich wrote:
> On 04.12.2020 12:45, Julien Grall wrote:
> >      1) From the recent security issues (such as XSA-343), a knob to
> > disable FIFO would be quite beneficials for vendors that don't need the
> > feature.
> Except that this wouldn't have been suitable as a during-embargo
> mitigation, for its observability by guests.
I think you are missing my point here. If that knob was available before 
the security event, a vendor may have already decided to use it to 
disable feature affected.
This vendor would not have needed to spend time to either hotpatch or 
reboot all its fleet.
> >      2) Fleet management purpose. You may have a fleet with multiple
> > versions of Xen. You don't want your customer to start relying on
> > features that may not be available on all the hosts otherwise it
> > complicates the guest placement.
> Guests incapable to run on older Xen are a problem in this regard
> anyway, aren't they? And if they are capable, I don't see what
> you're referring to.
It is not about guest that cannot run on older Xen. It is more about 
allowing a guest to use a feature that is not yet widely available in 
the fleet (you don't update all the hosts in a night...).
Imagine the guest owner really wants to use feature A that is only 
available on new Xen version. The owner may have noticed the feature on 
an existing running guest and would like to create a new guest that use 
the feature.
It might be possible that there are no capacity available on the new Xen 
version. So the guest may start on an older capacity.
I can assure you that the owner will contact the customer service of the 
cloud provider to ask why the feature is not available on the new guest.
With a knob available, a cloud provider has more flexibility to when the 
feature can be exposed.
> > FAOD, I am sure there might be other features that need to be disabled.
> > But we have to start somewhere :).
> If there is such a need, then yes, sure. But shouldn't we at least
> gain rough agreement on how the future is going to look like with
> this? IOW have in hands some at least roughly agreed criteria by
> which we could decide which new ABI additions will need some form
> of override going forward (also allowing to judge which prior
> additions may want to gain overrides in a retroactive fashion, or
> in fact should have had ones from the beginning)?
I think the answer is quite straight-forward: Anything exposed to the 
non-privileged (I include stubdomain) guest should have a knob to 
disable it.
> > > > Now imagine you are the cloud provider, running Xen. What you did was start to 
> > > > upgrade your hosts from an older version of Xen to a newer version of Xen, to 
> > > > pick up various bug fixes and make sure you are running a version that is 
> > > > within the security support envelope. You identify that your customer's problem 
> > > > is a bug in their OS that was latent on the old version of the hypervisor but 
> > > > is now manifesting on the new one because it has buggy support for a hypercall 
> > > > that was added between the two versions. How are you going to fix this issue, 
> > > > and get your customer up and running again? Of course you'd like your customer 
> > > > to upgrade their OS, but they can't even boot it to do that. You really need a 
> > > > solution that can restore the old VM environment, at least temporarily, for 
> > > > that customer.
> > > Boot the guest on a not-yet-upgraded host again, to update its kernel?
> > You are making the assumption that the customer would have the choice to
> > target a specific versions of Xen. This may be undesirable for a cloud
> > provider as suddenly your customer may want to stick on the old version
> > of Xen.
> I've gone from you saying "You really need a solution that can restore
> the old VM environment, at least temporarily, for that customer." The
> "temporarily" to me implies that it is at least an option to tie a
> certain guest to a certain Xen version for in-guest upgrading purposes.
>
> If the deal with the customer doesn't include running on a certain Xen
> version, I don't see how this could have non-temporary consequences to
> the cloud provider.
I think by "you", you mean Paul and not me?

Cheers,

--
Julien Grall