Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Mon, Jan 8, 2018 at 9:45 AM, Ian Jackson <ian.jackson@xxxxxxxxxxxxx> wrote:
> AIUI we have a series for pv-in-pvh shim which is nearing completion
> in the sense that it will have been well-tested (especially the
> hypervisor parts) and has good functionality.  (Wei is handling the
> assembly of this series.)
>
> The series, however, needs proper review and tidying up.
> Specifically, it needs the kind of tidying up that fixes code
> structure and style issues that will hinder future Xen development.
> I.e. the kind of technical debt which does not directly cause bugs now
> but will cause trouble (including bugs) in the future.
>
> IMO that kind of tidying up is definitely essential for
> xen.git#master.  However, it is much less of an issue for Xen 4.10.
> Xen 4.10, as a stable branch, will get much more limited further
> development.  Failure to tidy things up there will make backporting
> other changes more awkward but the overall impact is both lower and
> time-bound.
>
> Currently the Xen Project has no published resolution for PV guests
> that can't be booted as, or converted to, PVH or HVM.  (And HVM guests
> bring their own problems.)  We need to provide our users with more
> good options as quickly as possible.
>
> I would like to suggest that a good way of doing this would be to ship
> the shim series as 4.10.1 within the next very few days.  It needs
> some minor bugfixing (build breakage etc.) but is basically ready for
> use.
>
> Speaking as a sysadmin (even, a very conservative sysadmin many of
> whose systems are running Debian oldstable), I have already taken a
> decision to rapidly advance to new software, in one context, because
> of these vulnerabilities - and take and fix whatever impact that has.
> I think many of our users would like to make the same choice.
>
> Releaseing 4.10.1 this week with pv-in-pvh support would give many of
> our users with PV guests an immediately deployable update, even though
> of course the version bump to get to 4.10 may be disruptive.
>
> Doing this would be a departure from our uusual non-security-bug
> process of committing changes to xen.git#staging, and then backporting
> only after the patches have been sitting in xen.git#master for some
> time.  It's also a departure from our usual security-bug process of
> developing and testing and committing patches for all supported
> versions in parallel.
>
> But this is not a usual situation.  This time, we don't have the time
> to wait.
>
> Opinions ?

Whatever solution is chosen, I agree getting a solution merged and a new
release cut is critical.  Getting variant 2 addressed is also
important but variant
3 is a much bigger practical risk IMHO.

Regards,

Anthony Liguori

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

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