xen-stable vs. xen-testing

xen-stable vs. xen-testing

[Derek Glidden]

So given the recent announcement of the linux local-privilege-escalation 
I want to upgrade my Xen box/VM to the latest kernel.  I see that the 
xen-2.0 tree still has 2.6.9 and xen-testing has 2.6.10 patches.  So I 
have a few questions:

a) how stable is "testing" really?

b) can I just build new kernels from the -testing tree or should I build 
the Xen VMM as well?

c) do any of the Xen folks track BUGTRAQ or anything to keep up on 
potential kernel-level bugs that should be addressed relatively quickly? 
  Granted, I don't think I've seen a legitimate linux kernel exploit in 
like four or five years now, but should another one pop up and I do 
track security lists would it be worth my effort to relay the info to 
the xen-list?

d) I realize that Xen is really still R&D for the most part, but how do 
the Xen team feel about security issues like this?


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

RE: xen-stable vs. xen-testing

[Ian Pratt]

> So given the recent announcement of the linux 
> local-privilege-escalation 
> I want to upgrade my Xen box/VM to the latest kernel.  I see that the 
> xen-2.0 tree still has 2.6.9 and xen-testing has 2.6.10 
> patches.  So I 
> have a few questions:
> 
> a) how stable is "testing" really?

Usually pretty good. You see the odd followup patch or revert before a
release, but I don't think there have been too many shockers. (Hmm,
though I just thought of one from a couple of weeks back :-)
 
> b) can I just build new kernels from the -testing tree or 
> should I build 
> the Xen VMM as well?

You should just be able to build new kernels, but I'd recommend building
both otherwise you'll have a configuration that has never been tested
together.

> c) do any of the Xen folks track BUGTRAQ or anything to keep up on 
> potential kernel-level bugs that should be addressed 
> relatively quickly? 

Typically we just release a new kernel as soon as Linus/Andrew does.
We're usually have the new version out within a couple of days.

>   Granted, I don't think I've seen a legitimate linux kernel 
> exploit in 
> like four or five years now, but should another one pop up and I do 
> track security lists would it be worth my effort to relay the info to 
> the xen-list?

Feel free to, but we generally only prefer to release arch Xen patches
against official versions of the kernel. We could add a line to
buildconfigs/mk.linux-2.6 which applies a standard patch, though.

Since the vast majority of kernel exploits turn out to be bugs in arch
independent common code, you'll probably find the standard patch applies
just fine.
 
> d) I realize that Xen is really still R&D for the most part, 
> but how do 
> the Xen team feel about security issues like this?

We certainly care about security, but more so in our own code.

Best,
Ian


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: xen-stable vs. xen-testing

[Mark Williamson]

> a) how stable is "testing" really?

Should be pretty good, on average.  It's just smallish updates & fixes to the 
stable 2.0 tree.  Nothing controversial is likely to go in there.

> b) can I just build new kernels from the -testing tree or should I build
> the Xen VMM as well?

The plan is that interfaces will not change for the whole 2.x series, so I 
think it should work without rebuilding Xen.  Of course, the Xen in -testing 
will contain some fixes + features itself... ;-)

> d) I realize that Xen is really still R&D for the most part, but how do
> the Xen team feel about security issues like this?

Security of Xen itself and the XenLinux patch are extremely important to us.  
Ensuring that people can use an up-to-date mainline kernel (which may 
incorporate security fixes) is also quite a high priority.

The actual patches to fix generic Linux vulnerabilities are left to mainline 
developers or distributors, however.

Cheers,
Mark


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt