Re: Xen 4.1.x security support

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

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