From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?TWFyZWsgTWFyY3p5a293c2tpLUfDs3JlY2tp?= Subject: Re: Xen 4.1.x security support Date: Tue, 17 Sep 2013 22:36:49 +0200 Message-ID: <5238BD61.7070901@invisiblethingslab.com> References: <52377FC0.6000302@invisiblethingslab.com> <5238172E02000078000F3DBB@nat28.tlf.novell.com> <52389387.10008@invisiblethingslab.com> <52389516.7020905@invisiblethingslab.com> <1379445486.11304.195.camel@hastur.hellion.org.uk> <5238B3AA.3090805@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7899279492470278262==" Return-path: In-Reply-To: <5238B3AA.3090805@invisiblethingslab.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Joanna Rutkowska Cc: Ian Campbell , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============7899279492470278262== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2SSHTIQGPWKVWJEWFFOAE" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SSHTIQGPWKVWJEWFFOAE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17.09.2013 21:55, Joanna Rutkowska wrote: > On 09/17/13 21:18, Ian Campbell wrote: >> On Tue, 2013-09-17 at 19:44 +0200, Joanna Rutkowska wrote: >>> On 09/17/13 19:38, Joanna Rutkowska wrote: >>>> On 09/17/13 08:47, Jan Beulich wrote: >>>>>>>> On 17.09.13 at 00:01, Marek Marczykowski-G=C3=B3recki wrote: >>>>>> 4.1.6.1 was announced as the last 4.1.x release. Does it mean that= further >>>>>> XSAs will not carry patches for 4.1? >>>>> >>>>> That's the way I view it, but that doesn't mean it has to be that w= ay. >>>>> >>>> >>>> That would be rather unfortunate. E.g. we're planning to stick to Xe= n >>>> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 s= uch >>>> as the GPLPV Windows drivers not working with it correctly. >>>> >>>> I could imagine that it should not be very costly for xen.org to >>>> backport each XSA patch to 4.1, should it? >> >> Well, it rather depends on nature of the patch doesn't it. Some are ha= rd >> and some are easy. >> >> AFAIK the security team would be happy to receive and distribute >> additional backports to older versions done by community members e.g. >> those on the predisclosure list. >> >>> And a somehow more general thought: what most people expect from >>> baremetal hypervisors, I think, is stability. Unlike the Linux kernel= , >>> the Xen hypervisor does not need to support each and every device >>> invented on the planet, each and every possible filesystem, or >>> networking stack, etc. That's, in fact, (one of) the biggest advantag= e >>> of a hypervisor over a monolithic kernel. So, why, oh why, such a rac= e >>> to keep bumping the major version over and over again? >> >> What race are you talking about? Do you think we should do something >> other than bump the version when we cut a new release? or do you think= >> we should add features to stable branches or something? >> >=20 > My point was that you should be adding very few features or none at all= , > keep the hypervisor as simple as possible, do not change the management= > stack all the time, etc.=20 The only point that I agree with is do not change management *API* all th= e time. But this was recently discussed (libxl API stability) and things ar= e going in the right direction. Libxl in 4.1 was marked as technology previ= ew and starting from 4.2 should be stable. I haven't tried 4.3 yet, but I be= lieve that it is compatible with 4.2 in that matter. The other features (which you say shouldn't exists) are for example[1]: * Scalability: 16TiB of RAM * CPUID-based idle (don't rely on ACPI info f/ dom0) * NUMA scheduler affinity * Default to QEMU upstream (partial) - pci pass-thru (external) - enable dirtybit tracking during migration (external) - xl cd-{insert,eject} (external) * Serial console improvements -EHCI debug port Which of them are useless *for all Xen users*? Actually at least "CPUID-b= ased idle" and "QEMU upstream" (when done for stubdom) are quite useful even f= or Qubes OS. And the former one is strictly hypervisor feature (the only pla= ce where is enough information to manage power for the whole system). [1] http://wiki.xen.org/wiki/Xen_Roadmap/4.3 > Otherwise it makes it difficult for other > projects/products who use Xen to catch up. What version does Xen Client= > use, BTW? >=20 > Really, who needs nested virtualization, or XSM -- these are of pure > academic interest and only make the hypervisor unnecessary bloated, IMO= =2E Uh, the fact that Qubes OS doesn't need feature X doesn't mean that nobod= y needs it. Actually nested virtualization is quite useful for some environ= ments. > Why not keep everything that is not "core" as separate repos/projects, > conditionally compiled/linked with the core hypervisor? >=20 > When a hypervisor gets too complex it suddenly looses all its appeal > over a traditional kernel, doesn't it? --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? ------enig2SSHTIQGPWKVWJEWFFOAE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSOL1hAAoJENuP0xzK19csGF8H/3eRUhq50vvWKF7xu90s1L3I Jj4gdf/xO6OD6v0BGCBN8tKwKnELBK51auRFhuk75wdB36INDcgSACOrtVcizlfu m+jEqnhfMSV3PnijAAUTPkSi38tSJ3B8c+b2bY9HnwTb9/MPd9d4DMKja1FrqB52 apti8i8/A71+OPcLamXmlH/thL5BhNotuKC0ypENCjgaQEdx04GaBBXugsrVjqqZ gAP1z62Zfvsx4a+baCwvrHaeHcd6v6W+FMsHYTb2zyeomTV4eUiEuUfor9KtcxAm kA+BoymZELrNnqPuQtM3Qi1olKjYOcsAGkx/DMWtFP/qJjW3m5Xnydj1FVqAhFk= =kYDW -----END PGP SIGNATURE----- ------enig2SSHTIQGPWKVWJEWFFOAE-- --===============7899279492470278262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7899279492470278262==--