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

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

[Stefano Stabellini]

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

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


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

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

[Ian Jackson]

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>

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

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

[Doug Goldstein]

[-- Attachment #1.1: Type: text/plain, Size: 1889 bytes --]

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

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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

[Lars Kurth]

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

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

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

[Stefano Stabellini]

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@lists.xen.org
http://lists.xen.org/xen-devel