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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Jan 09, 2018 at 07:43:51PM +0000, Wei Liu wrote:
> On Mon, Jan 08, 2018 at 05:45:32PM +0000, 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 ?
> > 
> 
> Anthony and others joined #xendevel to express their findings and
> opinions.
> 
> Converging the PVH and HVM solution is doable and essential in the long
> run, but merging the two series in two or three days (if we want to make
> something ready this week) is not possible. It all comes down to which
> series should we use for the temporary solution.
> 
> We discussed the test coverage of both series. It seems that the PV in
> PVH series has had in depth testing done on 4.7 and 4.10, while PV in
> HVM series has had testing done from Xen 3.4 onward with various old and
> new guests. Anthony also pointed out that PV in PVH shim won't work for
> some configurations -- there are far too many subtleties to fix without
> time and testing resources (both of which upstream lacks). These are
> rather strong arguments for the PV in HVM series, because being able to
> run on older versions of Xen and older versions of guest kernels
> provides our users with the maximum coverage.
> 
> An argument for PV in PVH series is that it has more functionalities,
> but I think migration etc are just nice-to-have's in the context of this
> security fix series.
> 
> I think providing a well tested solution to our users as soon as
> possible, even if the solution has reduced functionality, is better than
> delaying for the perfect solution.  I suggest we go with Amazon's series
> first and produce something this week, then we seek to merge the two
> solutions. Anthony has agreed to be on the hook to review future
> patches. ;-)

I think this point is moot the moment vixen starts merging code from
the pvshim branch, at which point we get some kind of Frankenstein
shim which has more functionality than the original vixen code, but
has neither been tested by Amazon nor by Citrix, ie: the worse of both
scenarios.

If the vixen series has to be merged, I think the version merged
should be the one extensively tested by Amazon, or else the testing
point in the argument above it's just not true.

Roger.

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