[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.1.x security support
On Tue, 2013-09-17 at 22:36 +0200, Marek Marczykowski-GÃrecki wrote: > 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Ãrecki<marmarek@xxxxxxxxxxxxxxxxxxxxxx> 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 way. > >>>>> > >>>> > >>>> That would be rather unfortunate. E.g. we're planning to stick to Xen > >>>> 4.1 for our Qubes R2 release. There are some problems with Xen 4.2 such > >>>> 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 hard > >> 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 advantage > >>> of a hypervisor over a monolithic kernel. So, why, oh why, such a race > >>> 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? > >> > > > > 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. > > The only point that I agree with is do not change management *API* all the > time. But this was recently discussed (libxl API stability) and things are > going in the right direction. Libxl in 4.1 was marked as technology preview > and starting from 4.2 should be stable. I haven't tried 4.3 yet, but I believe > that it is compatible with 4.2 in that matter. Yes. If it isn't meeting the compatiblity guidelines written in libxl.h then we would like the know about it, please! > 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*? Exactly. None of them are useless for everyone, most of them are useful to a wide variety of people, although that doesn't necessarily always include client virtualisation. > Actually at least "CPUID-based > idle" and "QEMU upstream" (when done for stubdom) are quite useful even for > Qubes OS. And the former one is strictly hypervisor feature (the only place > 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? > > > > Really, who needs nested virtualization, or XSM -- these are of pure > > academic interest and only make the hypervisor unnecessary bloated, IMO. > > Uh, the fact that Qubes OS doesn't need feature X doesn't mean that nobody > needs it. yes, thanks for putting it so succinctly ;-) I really am done with this thread now, honest ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |