[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. -- Fajar _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |