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

[Xen-users] Integrating xen into existing kernel build processes



Hi,

I have an elaborate procedure to build new kernels and out-of-tree
modules in differently patched versions and configurations. This
procedure is based on Debians kernel build procedures, using
kernel-package, which can automatically apply and back out patches
delivered in a kind of specialized format as Debian packages. Now, I
would like to introduce Xen 3.x into that game.

I do not have practical experience with Xen yet, and I am far away
from being a kernel hacker.

Since Xen uses its own kernel build mechanism, a few questions have
surfaced, and I'd appreciate if somebody could take the time to answer.



(1)
In the Xen sources, there is a sparsely populated kernel tree, and a
set of patches. The build process downloads a linux 2.6.12 from
kernel.org and builds a symlink farm to connect the sparse tree and the
pristine upstream tree to each other before invoking the actual build.

(1a)
Did I correctly understand this?

(1b)
Where do the patches play in that game? Are they applied to the
pristine upstream tree, or to the resulting link farm?

(1c)
How does the build process determine that 2.6.12 is the kernel versio
that should be built?
Is it the setting in buildconfigs/mk.linux-2.6-*?

(1d)
What is the recommended way to generate a linux-2.6.12-xen.tar.bz2
kernel tree?



(2)
The sparse tree is around 4 MB large, and contains both new files and
files that already exist in the pristine upstream tree.

(2a)
Do I see correctly that some upstream files are completely replaced by
the ones that come from the sparse xen tree?

(2b)
Why was this method of distribution chosen over a more conservative
kernel patch?

(2c)
Do I see correctly that the patch is so invasive that the chance to
successfully xenize a more current kernel like 2.6.14 or even .15
without both intimate knowledge of Xen and the kernel is quite near zero?



(3)
How do I protect my Xenized kernel against the
local-privilege-escalation-exploit-of-the-week which keep surfacing
too often these days?

(3a)
Is there (unofficial?) support of later kernels for Xen 3.x without
having to resort to unstable or testing Xen versions?

(3b)
Is there (unofficial?) security support for the xenized 2.6.12 kernel
that is built by the Xen 3.x stable build process?

(3c)
Or do I have to sift through the lkml myself, deciding which patches
are security relevant or not?

(3d)
How do other people address the issue of kernel security with Xen?



Thanks for your consideration, I'd appreciate answers, pointers to
docs, and maybe even discussion.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

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