[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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



 


Rackspace

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