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

Re: [PATCH v2 2/2] xen/include/public: deprecate GNTTABOP_transfer



On 25.02.22 11:30, Jan Beulich wrote:
On 25.02.2022 11:24, Julien Grall wrote:
On 25/02/2022 08:12, Jan Beulich wrote:
On 24.02.2022 23:55, Julien Grall wrote:
On 16/02/2022 09:29, Jan Beulich wrote:
On 16.02.2022 08:20, Juergen Gross wrote:
On 15.02.22 22:13, Julien Grall wrote:
As a side note, should we also update SUPPORT.md?

Good question.

I'm not sure here either - talking about individual hypercall sub-ops
seems overly small granularity to me for this kind of doc. Plus I
don't view deprecation and de-supporting as the same thing. The latter
would mean to render unsupported any old XenoLinux which may still be
in use, all of the sudden.

I understand this would result to unsupport some old OSes (not clear how
old). However, from what Juergen said this feature is untested.

To me it sound like we are not confident that we could security support
this feature.

So I am not sure to understand why we only want to deprecate it.

Not sure what to say: Rendering unsupported however old guests is not
a nice step. Hence my concern (which isn't an outright objection).

In the past we have removed support for feature we deemed unsafe to use
and it would require effort to secure it. This is despite the fact that
it may be used in production (e.g. PV devices, qemu trad...).

So I think the question here is really, do you think we can sensibly
security support GNTTABOP_transfer?

I don't think it's a question of "can", but of "are we willing to". It
would be "can" only if we learned of some seemingly very hard to solve
issue. From a workload perspective it would certainly be nice if we
didn't have to think about this anymore. Yet like in certain other
cases, besides the particular item here I'm also worried of setting
a precedent which may then be used to argue for the removal of support
for other operations, just to make our lives easier.

Just one comment: desupporting GNTTABOP_transfer would hit only systems
with a XenoLinux dom0. I think those running on a still supported Xen
version are really rare these days.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


 


Rackspace

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