[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen 3.4.x Backports

On Wed, Feb 29, 2012 at 6:51 AM, Jonathan Tripathy <jonnyt@xxxxxxxxxxx> wrote:
> On 28/02/2012 23:47, Fajar A. Nugraha wrote:
>> On Wed, Feb 29, 2012 at 6:36 AM, Jonathan Tripathy<jonnyt@xxxxxxxxxxx>
>>  wrote:
>>> CVE-2011-1166
>>> https://bugzilla.redhat.com/show_bug.cgi?id=688579
>>> http://xenbits.xen.org/hg/staging/xen-unstable.hg/rev/c79aae866ad8
>>> Again, this doesn't appear to be backported to 3.4.x, however I note that
>>> Red Hat claim to have fixed this in their kernel version. This is where I
>>> get confused again. How can a hypervisor issue be fixed in the kernel??
>> Redhat bundles the hypervisor (xen.gz) as part of their kernel-xen
>> rpm, while xen rpm only contains the userland part. So if you have
>> three different versions of kernel-xen rpm installed, you'd have three
>> versions of hypervisors.
> Interesting!
> What we currently do is use CentOS's kernel-xen purely for the Linux Kernel,
> however we use the xen.gz (3.4.x) image from GitCo. Is this bad?

It depends :)

> It's been a
> very stable combination for us.
> I take it this means, for my security concerns, that I have to rely on what
> has been backported to the 3.4.x branch in xenbits, as I'm not using Red
> Hat's backports?

You could take a look at what redhat has done, and see if you can
integrate the patches into Gitco's RPM.

If you only use block device backend (i.e. phy:/), it might be easier
to just switch to xen-4.1.2 + latest upstream kernel (e.g. using
kernel-ml 3.x rpm from elrpo.org). That way you can easily apply
latest security patches yourself, without having to backport it.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.