Re: Xen 4.1.x security support

[Ian Campbell <ian.campbell@citrix.com>]

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