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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/01/2018 17:45, Ian Jackson 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 ?

Given the situation, getting a mitigation in place is urgent.  That
said, we should err on the side of haste rather than panic.

As a first requirement, nothing should go into 4.10 which isn't in
staging.  (The two are very close together at the moment but) the moment
we start committing straight to 4.10, we will loose some subtle change
from staging, and it will take ages to spot.  What I mean by this is
that, if we agree to go along this route, patches should be committed to
staging then immediately cherrypicked to staging-4.10, rather than
committed to staging-4.10 directly.  This ensures that we don't
accidentally miss functionality in the mainline.

We must ensure that perfection doesn't get in the way of expediency. 
Therefore, reviews should be extra careful about which review comments
are nice-to-have, and which are mandatory.  Technical arguments are part
of the course, but should compromise on the easier solution when it
doesn't affect a correctness issue.

Some nice-to-haves (such as minor corrections to coding style) can be
easily fixed on commit.  Not-so-minor nice-to-haves which still don't
impact the technical correctness of the issue should be deferred.  The
list of not-so-minor nice-to-haves should be maintained and be blockers
for 4.11 (as the code wouldn't have normally gotten in), and for want of
anyone better, I nominate Juergen as the release manager for 4.11 to be
in charge of this list.

Does this sound fair?  Pressing times call for extraordinary measures,
but in this case, I think it is the better course of action for the
project as a whole.

~Andrew

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