Xen 4.1.x security support

Xen 4.1.x security support

[Marek Marczykowski-Górecki]

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

Hi all,

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? If they will - how long?

-- 
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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 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: Xen 4.1.x security support

[Jan Beulich]

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

Jan

> If they will - how long?


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

Re: Xen 4.1.x security support

[Joanna Rutkowska]

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

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?

Thanks,
joanna.



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 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: Xen 4.1.x security support

[Joanna Rutkowska]

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

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?
> 

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?

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 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: Xen 4.1.x security support

[Ian Campbell]

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?

The release cadence has been discussed on the list fairly recently. I
would suggest you make your views known under that topic rather than
here where people might miss it.

Ian.


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

Re: Xen 4.1.x security support

[Joanna Rutkowska]

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

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

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 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: Xen 4.1.x security support

[Marek Marczykowski-Górecki]

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

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.

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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 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: Xen 4.1.x security support

[Ian Campbell]

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

Re: Xen 4.1.x security support

[Ian Campbell]

On Tue, 2013-09-17 at 21:55 +0200, Joanna Rutkowska wrote:
> On 09/17/13 21:18, Ian Campbell wrote:
> 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.

I think "all the time" is a gross exaggeration TBH.

>  Otherwise it makes it difficult for other
> projects/products who use Xen to catch up. What version does Xen Client
> use, BTW?

I don't know. I'm not sure why you think I would.

> Really, who needs nested virtualization, or XSM -- these are of pure
> academic interest and only make the hypervisor unnecessary bloated, IMO.

Well, that's *your* opinion.

BTW if you want a version of Xen without those things to continue to be
supported then you are very welcome to volunteer to take over
maintenance of the 4.0 (or any, I don't know how far back you'd need to
go to predate XSM for example) stable branch once xen.org support runs
out.

> Why not keep everything that is not "core" as separate repos/projects,
> conditionally compiled/linked with the core hypervisor?

Because that would be an unmanageable nightmare for everyone involved?

> When a hypervisor gets too complex it suddenly looses all its appeal
> over a traditional kernel, doesn't it?

TBH I think you are either focused on only your own needs/requirements
or maybe you are just trolling, in which case I sadly appear to have
fallen for it. In any case I don't think I'll bother reading the rest of
this thread.

Ian.

Re: Xen 4.1.x security support

[Vincent Hanquez]

On 09/17/2013 08:55 PM, Joanna Rutkowska wrote:
> What version does Xen Client use, BTW?

We are currently on 4.3.

> Really, who needs nested virtualization, or XSM -- these are of pure
> academic interest and only make the hypervisor unnecessary bloated, IMO.
Not sure what you're talking about here, since XenClient actually want 
(or already do) make use of both
nested virtualization and XSM.

-- 
Vincent

Re: Xen 4.1.x security support

[Joanna Rutkowska]

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

On 09/18/13 12:03, Vincent Hanquez wrote:
> On 09/17/2013 08:55 PM, Joanna Rutkowska wrote:
>> What version does Xen Client use, BTW?
> 
> We are currently on 4.3.
> 
>> Really, who needs nested virtualization, or XSM -- these are of pure
>> academic interest and only make the hypervisor unnecessary bloated, IMO.
> Not sure what you're talking about here, since XenClient actually want
> (or already do) make use of both
> nested virtualization and XSM.
> 

Features like those do weaken hypervisor security.

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 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: Xen 4.1.x security support

[Jan Beulich]

>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> 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?

In fact I'm the (so far apparently only) one trying to stop further
accelerating the release schedule from its original 9 month cycle.
I don't recall you having chimed in when the release schedule for
4.4 in particular and the shortening of the release cycle in general
was discussed on the mailing list. There were arguments in favor
of the shortening which I certainly appreciate.

As a side note - last we bumped the _major_ version was in Spring
2010, so over 3 years ago. But I guess by "major" you really
meant "minor", which corresponds to a major release (as opposed
to a stable one).

Jan

Re: Xen 4.1.x security support

[Joanna Rutkowska]

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

On 09/18/13 10:39, Jan Beulich wrote:
>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
>> 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?
> 
> In fact I'm the (so far apparently only) one trying to stop further
> accelerating the release schedule from its original 9 month cycle.
> I don't recall you having chimed in when the release schedule for
> 4.4 in particular and the shortening of the release cycle in general
> was discussed on the mailing list. There were arguments in favor
> of the shortening which I certainly appreciate.
> 

Well, I'm not regular on xen-devel, because I'm not a Xen developer,
really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
should not even maintain a fork of Xen, nor be at xen-devel at all.

I just came here now because I'm worried that the team I'm leading, the
users of Xen, will now need to spend considerable amount of time on
upgrading our product to Xen 4.2, because Xen 4.1 security support is
ending soon. I can imagine there are more users of Xen who would share
my worries, hopefully they will come to this threat sooner or later and
back me up :)

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 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: Xen 4.1.x security support

[Sander Eikelenboom]

Wednesday, September 18, 2013, 10:39:24 AM, you wrote:

>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
>> 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?

> In fact I'm the (so far apparently only) one trying to stop further
> accelerating the release schedule from its original 9 month cycle.
> I don't recall you having chimed in when the release schedule for
> 4.4 in particular and the shortening of the release cycle in general
> was discussed on the mailing list. There were arguments in favor
> of the shortening which I certainly appreciate.

> As a side note - last we bumped the _major_ version was in Spring
> 2010, so over 3 years ago. But I guess by "major" you really
> meant "minor", which corresponds to a major release (as opposed
> to a stable one).

I don't think it's about the version number, but more the number of major changes.
But i think it's quite clear they are for the better and if you argue you want a small core,
i think all major changes that affect the core are pretty stable now, so it would be worthwhile to migrate to 4.3.

The most current day problems and development seem to be with new stuff and incomplete support
(as to former xm/xend toolstack and qemu-xen-traditional) for more 'exotic' features as pci passthrough and the like.

And about the real major version number, perhaps a major bump to 5.0 is in fact warranted now
xend is perhaps removed from unstable before the release, i think that could be considered as a major milestone.

--
Sander

> Jan

Re: Xen 4.1.x security support

[George Dunlap]

On Wed, Sep 18, 2013 at 10:19 AM, Sander Eikelenboom
<linux@eikelenboom.it> wrote:
>
> Wednesday, September 18, 2013, 10:39:24 AM, you wrote:
>
>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
>>> 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?
>
>> In fact I'm the (so far apparently only) one trying to stop further
>> accelerating the release schedule from its original 9 month cycle.
>> I don't recall you having chimed in when the release schedule for
>> 4.4 in particular and the shortening of the release cycle in general
>> was discussed on the mailing list. There were arguments in favor
>> of the shortening which I certainly appreciate.
>
>> As a side note - last we bumped the _major_ version was in Spring
>> 2010, so over 3 years ago. But I guess by "major" you really
>> meant "minor", which corresponds to a major release (as opposed
>> to a stable one).
>
> I don't think it's about the version number, but more the number of major changes.
> But i think it's quite clear they are for the better and if you argue you want a small core,
> i think all major changes that affect the core are pretty stable now, so it would be worthwhile to migrate to 4.3.

We have had people report that in the past upgrading was a fairly
painful process, but that in recent releases, upgades have been pretty
painless.  We've added a lot of things to our process to try to make
that the case; the switch to a new toolstack, with explicit API
compatibility promises, was a part of that, as has been the addition
of more extensive regression testing facilities, test days before
releases, and so on.

So it may be worth trying an update to 4.3 -- it may be easier than you imagine.

 -George

Re: Xen 4.1.x security support

[Jan Beulich]

>>> On 17.09.13 at 19:38, Joanna Rutkowska <joanna@invisiblethingslab.com> 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?

Depends - there are cases (XSA-52, -53, and -55 for example)
where the backport is not straightforward. And doing backports
in the trivial cases, but not in the non-trivial ones would be sort
of odd.

That said, for the next few months at least we (SUSE) will need to
do backports to 4.1 too. But it's not clear to me whether it would
be sending the right sign if we were to include these in advisories
- after all, from a xen.org perspective we _want_ people to
recognize that dead trees are dead (unless someone steps up to
continue maintaining them, in which case it would also be that
someone to create the respective security fix backports, or at
least coordinate this between the parties doing such backports
anyway).

Jan

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

Re: Xen 4.1.x security support

[Joanna Rutkowska]

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

On 09/18/13 10:33, Jan Beulich wrote:
>>>> On 17.09.13 at 19:38, Joanna Rutkowska <joanna@invisiblethingslab.com> 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?
> 
> Depends - there are cases (XSA-52, -53, and -55 for example)
> where the backport is not straightforward. And doing backports
> in the trivial cases, but not in the non-trivial ones would be sort
> of odd.
> 
> That said, for the next few months at least we (SUSE) will need to
> do backports to 4.1 too. But it's not clear to me whether it would
> be sending the right sign if we were to include these in advisories
> - after all, from a xen.org perspective we _want_ people to
> recognize that dead trees are dead (unless someone steps up to
> continue maintaining them, in which case it would also be that
> someone to create the respective security fix backports, or at
> least coordinate this between the parties doing such backports
> anyway).
> 

Perhaps the decision to kill 4.1 branch so early should be revisited
then? This forces people who used Xen 4.1 to build products (e.g.
because back when they made the decision the 4.2 was still not released)
to make a significant work now to adopt the 4.2.

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 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: Xen 4.1.x security support

[Jan Beulich]

>>> On 18.09.13 at 10:37, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> On 09/18/13 10:33, Jan Beulich wrote:
>>>>> On 17.09.13 at 19:38, Joanna Rutkowska <joanna@invisiblethingslab.com> 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?
>> 
>> Depends - there are cases (XSA-52, -53, and -55 for example)
>> where the backport is not straightforward. And doing backports
>> in the trivial cases, but not in the non-trivial ones would be sort
>> of odd.
>> 
>> That said, for the next few months at least we (SUSE) will need to
>> do backports to 4.1 too. But it's not clear to me whether it would
>> be sending the right sign if we were to include these in advisories
>> - after all, from a xen.org perspective we _want_ people to
>> recognize that dead trees are dead (unless someone steps up to
>> continue maintaining them, in which case it would also be that
>> someone to create the respective security fix backports, or at
>> least coordinate this between the parties doing such backports
>> anyway).
>> 
> 
> Perhaps the decision to kill 4.1 branch so early should be revisited
> then?

Again - if you're willing to step up and maintain that tree, we
could consider that (just like 3.4 got maintained for an extended
period of time by a non-core-xen.org person).

To me, who does the maintenance of the stable trees, keeping
two of them up to date already requires non-neglectable amounts
of time. Three is too much for more than a brief overlapping
period - remember that there's other work I need and want to do.

And again - terminating maintenance of the second to last major
release tree after a last wrap-up stable release has been, if not
a written rule, a model we've been following for at least the last
couple of years.

An intermediate solution might be to _only_ put security fixes in
the least recently abandoned stable tree, and do another wrap-up
release once even that activity stops. But whether that would be
a good idea needs input from others (along with working out who's
going to do the resulting work).

Jan

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

Re: Xen 4.1.x security support

[Andres Lagar-Cavilla]

> On 09/18/13 10:39, Jan Beulich wrote:
>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
>>> 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?
>> 
>> In fact I'm the (so far apparently only) one trying to stop further
>> accelerating the release schedule from its original 9 month cycle.
>> I don't recall you having chimed in when the release schedule for
>> 4.4 in particular and the shortening of the release cycle in general
>> was discussed on the mailing list. There were arguments in favor
>> of the shortening which I certainly appreciate.
>> 
> 
> Well, I'm not regular on xen-devel, because I'm not a Xen developer,
> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
> should not even maintain a fork of Xen, nor be at xen-devel at all.
> 
> I just came here now because I'm worried that the team I'm leading, the
> users of Xen, will now need to spend considerable amount of time on
> upgrading our product to Xen 4.2, because Xen 4.1 security support is
> ending soon.

Several communities are adopting the notion of LTS releases. Ubuntu Precise, for example, has been a major enabler in Openstack by offering a steady platform for over 18 months now. Upstream kernel 3.10 is slated to underpin major distros for a good while.

I don't see why xen.org could not offer a similar cadence, and all the down streams would naturally align to that.

Jan's point about keeping many stable trees being a significant time sink is extremely valid.

I think the LTS solutions solves both of your problems. As a downstream, Qubes won't have to move rapidly crossing minor versions. There will be a reckoning day when transitioning to the next LTS, but you will have plenty of advance notice to prepare.

The stable tree maintainer needs to care about a single tree which is a very well known quantity, and not have to deal with maybe two or even three trees at a time.

One could argue that an LTS approach lessens the value of non LTS releases. In fact, discussions in Ubuntu have pointed at forgetting about non LTS releases and doing nightly builds in between, given a strong enough CI/CD environment. I for one think that's a bit too drastic and there is value to 4.3, 4.4, etc marking completion of important features.

If we were to appoint an LTS, I would vote for 4.2, which saw a significant delta with respect to 4.1.

If we were to appoint a 5.0, that would be a prime candidate for an LTS. Xend deprecation as well as fully-baked PVH would be two major milestones demarcating a clear before and after.

My two cents
Andres

> I can imagine there are more users of Xen who would share
> my worries, hopefully they will come to this threat sooner or later and
> back me up :)
> 
> joanna.
> 

Re: Xen 4.1.x security support

[George Dunlap]

On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla
<andreslc@gridcentric.ca> wrote:
>> On 09/18/13 10:39, Jan Beulich wrote:
>>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
>>>> 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?
>>>
>>> In fact I'm the (so far apparently only) one trying to stop further
>>> accelerating the release schedule from its original 9 month cycle.
>>> I don't recall you having chimed in when the release schedule for
>>> 4.4 in particular and the shortening of the release cycle in general
>>> was discussed on the mailing list. There were arguments in favor
>>> of the shortening which I certainly appreciate.
>>>
>>
>> Well, I'm not regular on xen-devel, because I'm not a Xen developer,
>> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
>> should not even maintain a fork of Xen, nor be at xen-devel at all.
>>
>> I just came here now because I'm worried that the team I'm leading, the
>> users of Xen, will now need to spend considerable amount of time on
>> upgrading our product to Xen 4.2, because Xen 4.1 security support is
>> ending soon.
>
> Several communities are adopting the notion of LTS releases. Ubuntu Precise, for example, has been a major enabler in Openstack by offering a steady platform for over 18 months now. Upstream kernel 3.10 is slated to underpin major distros for a good while.
>
> I don't see why xen.org could not offer a similar cadence, and all the down streams would naturally align to that.
>
> Jan's point about keeping many stable trees being a significant time sink is extremely valid.
>
> I think the LTS solutions solves both of your problems. As a downstream, Qubes won't have to move rapidly crossing minor versions. There will be a reckoning day when transitioning to the next LTS, but you will have plenty of advance notice to prepare.
>
> The stable tree maintainer needs to care about a single tree which is a very well known quantity, and not have to deal with maybe two or even three trees at a time.
>
> One could argue that an LTS approach lessens the value of non LTS releases. In fact, discussions in Ubuntu have pointed at forgetting about non LTS releases and doing nightly builds in between, given a strong enough CI/CD environment. I for one think that's a bit too drastic and there is value to 4.3, 4.4, etc marking completion of important features.
>
> If we were to appoint an LTS, I would vote for 4.2, which saw a significant delta with respect to 4.1.
>
> If we were to appoint a 5.0, that would be a prime candidate for an LTS. Xend deprecation as well as fully-baked PVH would be two major milestones demarcating a clear before and after.

Yes, I think we will need to go to designating a "stable hypervisor"
that will be supported for longer periods of time.  One aspect of
which one would be the best at this point is how many downstreams we
have using which release.  Debian, Ubuntu, and XenServer, for
instance, have older versions that use 4.1, I believe.  I'm not sure
how many downstreams we have using 4.2.

But this should be discussed in a way that will make sure all the
stakeholders are involved.

 -George

Re: Xen 4.1.x security support

[Pasi Kärkkäinen]

On Wed, Sep 18, 2013 at 04:42:05PM +0100, George Dunlap wrote:
> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla
> <andreslc@gridcentric.ca> wrote:
> >> On 09/18/13 10:39, Jan Beulich wrote:
> >>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
> >>>> 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?
> >>>
> >>> In fact I'm the (so far apparently only) one trying to stop further
> >>> accelerating the release schedule from its original 9 month cycle.
> >>> I don't recall you having chimed in when the release schedule for
> >>> 4.4 in particular and the shortening of the release cycle in general
> >>> was discussed on the mailing list. There were arguments in favor
> >>> of the shortening which I certainly appreciate.
> >>>
> >>
> >> Well, I'm not regular on xen-devel, because I'm not a Xen developer,
> >> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
> >> should not even maintain a fork of Xen, nor be at xen-devel at all.
> >>
> >> I just came here now because I'm worried that the team I'm leading, the
> >> users of Xen, will now need to spend considerable amount of time on
> >> upgrading our product to Xen 4.2, because Xen 4.1 security support is
> >> ending soon.
> >
> > Several communities are adopting the notion of LTS releases. Ubuntu Precise, for example, has been a major enabler in Openstack by offering a steady platform for over 18 months now. Upstream kernel 3.10 is slated to underpin major distros for a good while.
> >
> > I don't see why xen.org could not offer a similar cadence, and all the down streams would naturally align to that.
> >
> > Jan's point about keeping many stable trees being a significant time sink is extremely valid.
> >
> > I think the LTS solutions solves both of your problems. As a downstream, Qubes won't have to move rapidly crossing minor versions. There will be a reckoning day when transitioning to the next LTS, but you will have plenty of advance notice to prepare.
> >
> > The stable tree maintainer needs to care about a single tree which is a very well known quantity, and not have to deal with maybe two or even three trees at a time.
> >
> > One could argue that an LTS approach lessens the value of non LTS releases. In fact, discussions in Ubuntu have pointed at forgetting about non LTS releases and doing nightly builds in between, given a strong enough CI/CD environment. I for one think that's a bit too drastic and there is value to 4.3, 4.4, etc marking completion of important features.
> >
> > If we were to appoint an LTS, I would vote for 4.2, which saw a significant delta with respect to 4.1.
> >
> > If we were to appoint a 5.0, that would be a prime candidate for an LTS. Xend deprecation as well as fully-baked PVH would be two major milestones demarcating a clear before and after.
> 
> Yes, I think we will need to go to designating a "stable hypervisor"
> that will be supported for longer periods of time.  One aspect of
> which one would be the best at this point is how many downstreams we
> have using which release.  Debian, Ubuntu, and XenServer, for
> instance, have older versions that use 4.1, I believe.  I'm not sure
> how many downstreams we have using 4.2.
> 

At least the following rpm-based distros are currently shipping with Xen 4.2:

- Fedora 19
- CentOS6 Xen (not part of the distro, provided separately).


-- Pasi

> But this should be discussed in a way that will make sure all the
> stakeholders are involved.
> 
>  -George
> 

Re: Xen 4.1.x security support

[Sander Eikelenboom]

Thursday, September 19, 2013, 12:41:43 PM, you wrote:

> On Wed, Sep 18, 2013 at 04:42:05PM +0100, George Dunlap wrote:
>> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla
>> <andreslc@gridcentric.ca> wrote:
>> >> On 09/18/13 10:39, Jan Beulich wrote:
>> >>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
>> >>>> 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?
>> >>>
>> >>> In fact I'm the (so far apparently only) one trying to stop further
>> >>> accelerating the release schedule from its original 9 month cycle.
>> >>> I don't recall you having chimed in when the release schedule for
>> >>> 4.4 in particular and the shortening of the release cycle in general
>> >>> was discussed on the mailing list. There were arguments in favor
>> >>> of the shortening which I certainly appreciate.
>> >>>
>> >>
>> >> Well, I'm not regular on xen-devel, because I'm not a Xen developer,
>> >> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
>> >> should not even maintain a fork of Xen, nor be at xen-devel at all.
>> >>
>> >> I just came here now because I'm worried that the team I'm leading, the
>> >> users of Xen, will now need to spend considerable amount of time on
>> >> upgrading our product to Xen 4.2, because Xen 4.1 security support is
>> >> ending soon.
>> >
>> > Several communities are adopting the notion of LTS releases. Ubuntu Precise, for example, has been a major enabler in Openstack by offering a steady platform for over 18 months now. Upstream kernel 3.10 is slated to underpin major distros for a good while.
>> >
>> > I don't see why xen.org could not offer a similar cadence, and all the down streams would naturally align to that.
>> >
>> > Jan's point about keeping many stable trees being a significant time sink is extremely valid.
>> >
>> > I think the LTS solutions solves both of your problems. As a downstream, Qubes won't have to move rapidly crossing minor versions. There will be a reckoning day when transitioning to the next LTS, but you will have plenty of advance notice to prepare.

I don't think crossing future minor version would have to be a problem.
The major problem with the current 4.2 and 4.3 minor versions is that they are released in the 'middle' of the major switch of toolstack && qemu-upstream.
As a consequence they do have rough edges.


>> >
>> > The stable tree maintainer needs to care about a single tree which is a very well known quantity, and not have to deal with maybe two or even three trees at a time.
>> >
>> > One could argue that an LTS approach lessens the value of non LTS releases. In fact, discussions in Ubuntu have pointed at forgetting about non LTS releases and doing nightly builds in between, given a strong enough CI/CD environment. I for one think that's a bit too drastic and there is value to 4.3, 4.4, etc marking completion of important features.
>> >
>> > If we were to appoint an LTS, I would vote for 4.2, which saw a significant delta with respect to 4.1.
>> >
>> > If we were to appoint a 5.0, that would be a prime candidate for an LTS. Xend deprecation as well as fully-baked PVH would be two major milestones demarcating a clear before and after.

There are still some things which are not supported / do not work as documented in the libxl toolstack and/or upstream qemu.
Perhaps a testday should be spend on trying and validating all xend && xm && qemu-traditional options on xl && qemu-xen ?

Feature parity or at least corresponding documentation would be nice before doing an LTS or bumping the major.


>> Yes, I think we will need to go to designating a "stable hypervisor"
>> that will be supported for longer periods of time.  One aspect of
>> which one would be the best at this point is how many downstreams we
>> have using which release.  Debian, Ubuntu, and XenServer, for
>> instance, have older versions that use 4.1, I believe.  I'm not sure
>> how many downstreams we have using 4.2.
>> 

> At least the following rpm-based distros are currently shipping with Xen 4.2:

> - Fedora 19
> - CentOS6 Xen (not part of the distro, provided separately).


> -- Pasi

>> But this should be discussed in a way that will make sure all the
>> stakeholders are involved.
>> 
>>  -George
>> 

Re: Xen 4.1.x security support

[Jan Beulich]

>>> On 19.09.13 at 12:41, Pasi Kärkkäinen<pasik@iki.fi> wrote:
> At least the following rpm-based distros are currently shipping with Xen 4.2:
> 
> - Fedora 19
> - CentOS6 Xen (not part of the distro, provided separately).

- SLE11 SP3

Jan

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

Re: Xen 4.1.x security support

[M A Young]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4039 bytes --]



On Thu, 19 Sep 2013, Pasi Kärkkäinen wrote:

> On Wed, Sep 18, 2013 at 04:42:05PM +0100, George Dunlap wrote:
>> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla
>> <andreslc@gridcentric.ca> wrote:
>>>> On 09/18/13 10:39, Jan Beulich wrote:
>>>>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@invisiblethingslab.com> wrote:
>>>>>> 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?
>>>>>
>>>>> In fact I'm the (so far apparently only) one trying to stop further
>>>>> accelerating the release schedule from its original 9 month cycle.
>>>>> I don't recall you having chimed in when the release schedule for
>>>>> 4.4 in particular and the shortening of the release cycle in general
>>>>> was discussed on the mailing list. There were arguments in favor
>>>>> of the shortening which I certainly appreciate.
>>>>>
>>>>
>>>> Well, I'm not regular on xen-devel, because I'm not a Xen developer,
>>>> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
>>>> should not even maintain a fork of Xen, nor be at xen-devel at all.
>>>>
>>>> I just came here now because I'm worried that the team I'm leading, the
>>>> users of Xen, will now need to spend considerable amount of time on
>>>> upgrading our product to Xen 4.2, because Xen 4.1 security support is
>>>> ending soon.
>>>
>>> Several communities are adopting the notion of LTS releases. Ubuntu Precise, for example, has been a major enabler in Openstack by offering a steady platform for over 18 months now. Upstream kernel 3.10 is slated to underpin major distros for a good while.
>>>
>>> I don't see why xen.org could not offer a similar cadence, and all the down streams would naturally align to that.
>>>
>>> Jan's point about keeping many stable trees being a significant time sink is extremely valid.
>>>
>>> I think the LTS solutions solves both of your problems. As a downstream, Qubes won't have to move rapidly crossing minor versions. There will be a reckoning day when transitioning to the next LTS, but you will have plenty of advance notice to prepare.
>>>
>>> The stable tree maintainer needs to care about a single tree which is a very well known quantity, and not have to deal with maybe two or even three trees at a time.
>>>
>>> One could argue that an LTS approach lessens the value of non LTS releases. In fact, discussions in Ubuntu have pointed at forgetting about non LTS releases and doing nightly builds in between, given a strong enough CI/CD environment. I for one think that's a bit too drastic and there is value to 4.3, 4.4, etc marking completion of important features.
>>>
>>> If we were to appoint an LTS, I would vote for 4.2, which saw a significant delta with respect to 4.1.
>>>
>>> If we were to appoint a 5.0, that would be a prime candidate for an LTS. Xend deprecation as well as fully-baked PVH would be two major milestones demarcating a clear before and after.
>>
>> Yes, I think we will need to go to designating a "stable hypervisor"
>> that will be supported for longer periods of time.  One aspect of
>> which one would be the best at this point is how many downstreams we
>> have using which release.  Debian, Ubuntu, and XenServer, for
>> instance, have older versions that use 4.1, I believe.  I'm not sure
>> how many downstreams we have using 4.2.
>>
>
> At least the following rpm-based distros are currently shipping with Xen 4.2:
>
> - Fedora 19
> - CentOS6 Xen (not part of the distro, provided separately).

Though Fedora 20 will ship with Xen 4.3. The last Fedora version with Xen 
4.1 was Fedora 17 which is now out of support.

 	Michael Young

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

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

Re: Xen 4.1.x security support

[Stefan Bader]

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

On 18.09.2013 10:42, George Dunlap wrote:
> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla 
> <andreslc@gridcentric.ca> wrote:
>>> On 09/18/13 10:39, Jan Beulich wrote:
>>>>>>> On 17.09.13 at 19:44, Joanna Rutkowska
>>>>>>> <joanna@invisiblethingslab.com> wrote:
>>>>> 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?
>>>> 
>>>> In fact I'm the (so far apparently only) one trying to stop further 
>>>> accelerating the release schedule from its original 9 month cycle. I
>>>> don't recall you having chimed in when the release schedule for 4.4 in
>>>> particular and the shortening of the release cycle in general was
>>>> discussed on the mailing list. There were arguments in favor of the
>>>> shortening which I certainly appreciate.
>>>> 
>>> 
>>> Well, I'm not regular on xen-devel, because I'm not a Xen developer, 
>>> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project) 
>>> should not even maintain a fork of Xen, nor be at xen-devel at all.
>>> 
>>> I just came here now because I'm worried that the team I'm leading, the 
>>> users of Xen, will now need to spend considerable amount of time on 
>>> upgrading our product to Xen 4.2, because Xen 4.1 security support is 
>>> ending soon.
>> 
>> Several communities are adopting the notion of LTS releases. Ubuntu
>> Precise, for example, has been a major enabler in Openstack by offering a
>> steady platform for over 18 months now. Upstream kernel 3.10 is slated to
>> underpin major distros for a good while.
>> 
>> I don't see why xen.org could not offer a similar cadence, and all the down
>> streams would naturally align to that.
>> 
>> Jan's point about keeping many stable trees being a significant time sink
>> is extremely valid.
>> 
>> I think the LTS solutions solves both of your problems. As a downstream,
>> Qubes won't have to move rapidly crossing minor versions. There will be a
>> reckoning day when transitioning to the next LTS, but you will have plenty
>> of advance notice to prepare.
>> 
>> The stable tree maintainer needs to care about a single tree which is a
>> very well known quantity, and not have to deal with maybe two or even three
>> trees at a time.
>> 
>> One could argue that an LTS approach lessens the value of non LTS releases.
>> In fact, discussions in Ubuntu have pointed at forgetting about non LTS
>> releases and doing nightly builds in between, given a strong enough CI/CD
>> environment. I for one think that's a bit too drastic and there is value to
>> 4.3, 4.4, etc marking completion of important features.
>> 
>> If we were to appoint an LTS, I would vote for 4.2, which saw a significant
>> delta with respect to 4.1.
>> 
>> If we were to appoint a 5.0, that would be a prime candidate for an LTS.
>> Xend deprecation as well as fully-baked PVH would be two major milestones
>> demarcating a clear before and after.
> 
> Yes, I think we will need to go to designating a "stable hypervisor" that
> will be supported for longer periods of time.  One aspect of which one would
> be the best at this point is how many downstreams we have using which
> release.  Debian, Ubuntu, and XenServer, for instance, have older versions
> that use 4.1, I believe.  I'm not sure how many downstreams we have using
> 4.2.

Precise/12.04 is 4.1 based. Quantal/12.10 as well. Raring/13.04 is 4.2 based
(though its not a LTS release). I am trying to get all of them follow the
matching Xen stable releases during their life-time. The next LTS should have
Xen 4.3. So solely from my point of view selecting 4.3 as a Xen LTS would work
better but then I know this just started to introduce some quite big(ger)
changes and probably from the Xen side a later version would work better.

> 
> But this should be discussed in a way that will make sure all the 
> stakeholders are involved.
> 
> -George
> 
> _______________________________________________ Xen-devel mailing list 
> Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> 



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

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

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