Re: Xen 4.1.x security support

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

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