[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.1.x security support
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. 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-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. Actually nested virtualization is quite useful for some environments. > Why not keep everything that is not "core" as separate repos/projects, > conditionally compiled/linked with the core hypervisor? > > When a hypervisor gets too complex it suddenly looses all its appeal > over a traditional kernel, doesn't it? -- Best Regards, Marek Marczykowski-GÃrecki 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? Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |