Xen users - Jan 2006 - 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@lists.xensource.com
http://lists.xensource.com/xen-users

Hi,

you are using debian, so I would suggest the following to compile a xen3 
kernel:

put the following line in your /etc/apt/sources.list
"deb http://packages.debianbase.de/sarge/i386/xen3 ./"
(replace sarge with etch/sid if you are not using sarge(stable))

then run:
"apt-get update && apt-get install linux-patch-xen"

then you can donload a vanilla 2.6.12 kernel, for example with this line:
"wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.tar.bz2"
unpack the archive and chdir in it, then you can apply the xen-kernel patch 
with the following command:
"/usr/src/kernel-patch/i386/apply/xen"
this will patch the vanilla 2.6.12 kernel to a 2.6.12.6-xen kernel.
Now you can change the configuration of the kernel (if you like) with:
"make ARCH=xen menuconfig"
after that you can compile and package it with the following comand:
"make-kpkg --revision myversion1 --append_to_version .6-xen --arch xen 
kernel_image".
After this is completed you can install the new xen-kernel deb. You have to 
create a initrd yourself, because the make-kpkg doesn''t handle that for
xen
kernel-packages. The initrd can be created with:
"mkinitrd -o /boot/xen-modules-2.6.12.6-xen 2.6.12.6-xen"

But that is just the reuired steps for the kernel package, if you want to 
install xen3 on your debian box you should also make this:
"apt-get install xen bridge-utils"
(bridge-utils is only needed if you want to use a bridged network and not a 
routed one)

Last but not least you need an entry in your /boot/grub/menu.lst to boot xen3. 
THe following lines should do the trick:
"title           Xen 3 - Kernel 2.6.12-xen0
root            (hd0,6)
kernel          /boot/xen.gz
module          /boot/vmlinuz-2.6.12.6-xen root=/dev/hda7 ro
module          /boot/modules-2.6.12.6-xen
savedefault
boot"
(you may have to change "(hd0,6)" and "hda7" to your
root-device.)

Hope this helped :)

--Ralph

Am Donnerstag, 5. Januar 2006 10:17 schrieb Marc Haber:
> 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
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Thu, Jan 05, 2006 at 07:36:15PM +0100, Ralph Passgang
wrote:
> you are using debian, so I would suggest the following to compile a xen3 
> kernel:
(detailed description snipped)
> Hope this helped :)
It does, but I want to learn about the background. I am not a
HOWTO-type of guy, I need to know what''s going on behind the scenes.
Hence, my rather detailed catalog of questions.

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@lists.xensource.com
http://lists.xensource.com/xen-users