| Message ID | 1456415025-8364-1-git-send-email-stefano.stabellini@eu.citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Stefano Stabellini writes ("[PATCH] docs: spell out limits of security support for qemu-xen"):
> Write down what emulated hardware is supported in qemu-xen. Add a way
> for users to ask for a change in the list.
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
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).
On 26/02/2016 02:52, "Doug Goldstein" <cardoe@cardoe.com> 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
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.
diff --git a/docs/misc/qemu-xen-security b/docs/misc/qemu-xen-security new file mode 100644 index 0000000..4ab0b4d --- /dev/null +++ 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: + +- network: e1000, rtl8139, virtio-net +- storage: piix3 ide, ahci, xen_disk +- graphics: cirris-vga, stdvga and xenfb +- audio: sb16, es1370, ac97 +- input: Xen PV keyboard and mouse (part of xenfb), USB and PS/2 + keyboard and mouse +- serial cards: UART 16550A + +Core components, such as the PCI host bridge and the PIIX3 chipset, are +supported. All devices of one the above classes, which are not explicitly +mentioned, are not supported. For example the ne2000 network card is not +supported. + +If you think that a specific emulated device should be supported, please +contact the QEMU UPSTREAM maintainer and the Xen Security Team +(security@xenproject.org).
Write down what emulated hardware is supported in qemu-xen. Add a way for users to ask for a change in the list. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> CC: JBeulich@suse.com CC: Ian.Jackson@eu.citrix.com CC: lars.kurth@citrix.com CC: konrad.wilk@oracle.com --- docs/misc/qemu-xen-security | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 docs/misc/qemu-xen-security