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

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

On 26/02/2016 02:52, "Doug Goldstein" <cardoe@xxxxxxxxxx> 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.

I am wondering, whether making dependencies explicit would also make the
life of Xen based distributions easier. That is obviously something we
should verify.

>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. 

I agree, we are seeing more and more of this. Having clearer boundaries
and changing the model, would clearly help managing the increasingly bad
press coverage we are getting. For example, if you look at XSA's the rate
of XSA's we are discovering per year has been relatively stable per year,
but I have a hunch that it is actually decreasing if you remove QEMU and
other 3rd party XSA's we are handling.

>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).

I guess there is a debate to be have. Maybe this is something we can
discuss on here and next steps at the Hackathon. Konrad already put a
discussion in at 
http://wiki.xenproject.org/wiki/Hackathon/April2016#Security

Regards
Lars

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