Re: [Xen-devel] [PATCH] docs: spell out limits of security support for qemu-xen

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Thu, 25 Feb 2016, Doug Goldstein wrote:
> On 2/25/16 9:43 AM, Stefano Stabellini wrote:
> 
> > +++ b/docs/misc/qemu-xen-security
> > @@ -0,0 +1,20 @@
> > +qemu-xen (git://xenbits.xen.org/qemu-xen.git) is only supported for
> > +security fixes when used together with the Xen hypervisor and only with
> > +a subset of all the possible QEMU emulators. Specifically:
> 
> So I'll get my comments on paper here rather than something just
> mentioned on IRC. This is exactly why the Xen team should be pushing to
> remove as many "in-tree" items as possible. The security surface area of
> Xen is huge and statements like this help the CYA factor they don't
> completely eliminate the problems of manpower of having to check against
> different upstreams if a vulnerability affects you or downstreams doing
> something bad causing a security issue for users which ultimately gets
> blamed on Xen. There are then further complications where sometimes the
> version shipped by Xen isn't an upstream release and so there may be
> other vulnerabilities above and beyond what upstream announces.
> 
> I urge the Xen maintainers to make it a goal to remove external
> libraries and applications (like qemu-xen) from the tree entirely and
> recommend the use of the upstream release. I know the concern is testing
> but it involves calling out your dependencies just like you do any other
> dependency. (e.g. Xen X.Y requires QEMU A.B.C, no guarantees are made
> about the compatibility of other versions)
> 
> I know Stefano is making an effort with this with Project Raisin and
> really that should become the embraced way to stand up a "full" Xen
> system from source rather than a hodge podge collection of packages that
> are fetched by the Xen build system. This will bring the how developers
> use the source packages closer with how many users of distros use Xen
> (e.g. a number of distros use upstream QEMU releases instead of qemu-xen).

Thanks Doug, I fully agree with you.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel