Hi, I found lots of threads where people talk about domU kernel sitting in /boot of dom0. The only kernel I can see there is the one the machine and dom0 booted from (vmlinuz-2.6.18-8.el5xen) It seems that my domU''s have there own kernel inside the domU is there anything wrong with that or any disadvantages ? [root@serv106 ~]# ls -al /boot/ total 5380 drwxr-xr-x 3 root root 4096 Oct 11 18:20 . drwxr-xr-x 23 root root 4096 Oct 11 20:35 .. -rw-r--r-- 1 root root 61053 Mar 15 2007 config-2.6.18-8.el5xen drwxr-xr-x 2 root root 4096 Oct 11 18:32 grub -rw------- 1 root root 1398208 Oct 11 18:20 initrd-2.6.18-8.el5xen.img -rw-r--r-- 1 root root 80032 Apr 1 2007 message -rw-r--r-- 1 root root 84906 Mar 15 2007 symvers-2.6.18-8.el5xen.gz -rw-r--r-- 1 root root 868062 Mar 15 2007 System.map-2.6.18-8.el5xen -rw-r--r-- 1 root root 2074835 Mar 15 2007 vmlinuz-2.6.18-8.el5xen -rw-r--r-- 1 root root 274722 Mar 15 2007 xen.gz-2.6.18-8.el5 -rwxr-xr-x 1 root root 608564 Mar 15 2007 xen-syms-2.6.18-8.el5 [root@serv106 ~]# xm console centos5 [root@cento5 -]# cd /boot/ [root@cento5 boot]# ls -al total 5428 drwxr-xr-x 3 root root 4096 Oct 11 21:06 . drwxr-xr-x 23 root root 4096 Oct 12 00:04 .. -rw-r--r-- 1 root root 61053 Mar 15 2007 config-2.6.18-8.el5xen drwxr-xr-x 2 root root 4096 Oct 11 21:08 grub -rw------- 1 root root 1404212 Oct 11 21:06 initrd-2.6.18-8.el5xen.img -rw-r--r-- 1 root root 80032 Apr 1 2007 message -rw-r--r-- 1 root root 84906 Mar 15 2007 symvers-2.6.18-8.el5xen.gz -rw-r--r-- 1 root root 868062 Mar 15 2007 System.map-2.6.18-8.el5xen -rw-r--r-- 1 root root 2074835 Mar 15 2007 vmlinuz-2.6.18-8.el5xen -rw-r--r-- 1 root root 274722 Mar 15 2007 xen.gz-2.6.18-8.el5 -rwxr-xr-x 1 root root 608564 Mar 15 2007 xen-syms-2.6.18-8.el5 Thanks, Robin PS: didn''t mean to "flood" the mailing list, just lots of questions for a XEN beginner ..but will hopefully soon count to the answering and not asking guild. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Oct 12, 2007 at 12:14:02AM -0400, IDAGroup - R.W.Muller wrote:> Hi, I found lots of threads where people talk about domU kernel sitting > in /boot of dom0. > The only kernel I can see there is the one the machine and dom0 booted > from (vmlinuz-2.6.18-8.el5xen)Two places are common: - domU-kernel placed on dom0-filesystem directly, ''kernel'' option in xen- config for the domU is used then. Only possible for paravirt-domU. pros: - kernel is directly reachable from dom0 cons: - domU depends on files outside of its disc-image, so you have to keep an eye of what domU uses what kernel-file - on upgrading the domU-kernel is a bit more complicated, keep kernel, maybe existing initrd and modules-directory in sync - domU-kernel placed inside the domU-diskimage. Works for both HVM and paravirt-domU. One sees mostly this nowadays. Kernel is located/booted by pygrub (or a script mounting the partition, making a copy of the kernel inside to dom0, and starting it then) pros: - easy updating, i.e. just ''yum update'' from the domU updates the kernel, initrd, modules and kernel is booted on next domU-boot> PS: didn''t mean to "flood" the mailing list, just lots of questions for > a XEN beginner ..but will hopefully soon count to the answering > and not asking guild.Guess its all the same on mailinglists that 50% of the questions are defaultish ones that are probably in faqs all around answered.. Christian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Christian Horn wrote:> On Fri, Oct 12, 2007 at 12:14:02AM -0400, IDAGroup - R.W.Muller wrote: >> Hi, I found lots of threads where people talk about domU kernel sitting >> in /boot of dom0. >> The only kernel I can see there is the one the machine and dom0 booted >> from (vmlinuz-2.6.18-8.el5xen) > > Two places are common: > - domU-kernel placed on dom0-filesystem directly, ''kernel'' option in xen- > config for the domU is used then. Only possible for paravirt-domU. > pros: - kernel is directly reachable from dom0 > cons: - domU depends on files outside of its disc-image, so you have to > keep an eye of what domU uses what kernel-file > - on upgrading the domU-kernel is a bit more complicated, keep > kernel, maybe existing initrd and modules-directory in sync > > - domU-kernel placed inside the domU-diskimage. Works for both HVM and > paravirt-domU. One sees mostly this nowadays. Kernel is located/booted > by pygrub (or a script mounting the partition, making a copy of the > kernel inside to dom0, and starting it then) > pros: - easy updating, i.e. just ''yum update'' from the domU updates the > kernel, initrd, modules and kernel is booted on next domU-bootYou forgot the con. cons: Security. You now have a domU in which a local exploit could result in code being executed in dom0 at the next boot of that domU. By the way, this actually happened. See CVE-2007-4993 IMHO putting the kernel in domU and using pygrub was always asking for trouble. In my opinion it is completely crazy to expose dom0 to potential exploits from domU. So far as I am aware this is the *only* way to so expose dom0 to domU security holes and I am deeply shocked if it is true that "One sees mostly this nowadays" _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Wow, if that is true then is CentOS making a big mistake. When I installed CentOS with virtualization and started virt-install according to there howto, I was guided to install another CentOS domU but never asked to have a kernel outside the domU. So, I just even realized that this is possible, when I was reading this user list, before I thought the CentOS way is the only possibility ...so clearly: kernel IN domU Steve Wray wrote:> Christian Horn wrote: >> On Fri, Oct 12, 2007 at 12:14:02AM -0400, IDAGroup - R.W.Muller wrote: >>> Hi, I found lots of threads where people talk about domU kernel >>> sitting in /boot of dom0. >>> The only kernel I can see there is the one the machine and dom0 >>> booted from (vmlinuz-2.6.18-8.el5xen) >> >> Two places are common: >> - domU-kernel placed on dom0-filesystem directly, ''kernel'' option in >> xen- >> config for the domU is used then. Only possible for paravirt-domU. >> pros: - kernel is directly reachable from dom0 >> cons: - domU depends on files outside of its disc-image, so you >> have to keep an eye of what domU uses what kernel-file >> - on upgrading the domU-kernel is a bit more complicated, keep >> kernel, maybe existing initrd and modules-directory in sync >> >> - domU-kernel placed inside the domU-diskimage. Works for both HVM and >> paravirt-domU. One sees mostly this nowadays. Kernel is located/booted >> by pygrub (or a script mounting the partition, making a copy of the >> kernel inside to dom0, and starting it then) >> pros: - easy updating, i.e. just ''yum update'' from the domU updates >> the >> kernel, initrd, modules and kernel is booted on next domU-boot > > > You forgot the con. > > cons: Security. You now have a domU in which a local exploit could > result in code being executed in dom0 at the next boot of that domU. > By the way, this actually happened. See CVE-2007-4993 > > IMHO putting the kernel in domU and using pygrub was always asking for > trouble. > > In my opinion it is completely crazy to expose dom0 to potential > exploits from domU. > > So far as I am aware this is the *only* way to so expose dom0 to domU > security holes and I am deeply shocked if it is true that "One sees > mostly this nowadays" > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Steve Wray wrote:> Christian Horn wrote: >> On Fri, Oct 12, 2007 at 12:14:02AM -0400, IDAGroup - R.W.Muller wrote: >>> Hi, I found lots of threads where people talk about domU kernel >>> sitting in /boot of dom0. >>> The only kernel I can see there is the one the machine and dom0 >>> booted from (vmlinuz-2.6.18-8.el5xen) >> >> Two places are common: >> - domU-kernel placed on dom0-filesystem directly, ''kernel'' option in >> xen- >> config for the domU is used then. Only possible for paravirt-domU. >> pros: - kernel is directly reachable from dom0 >> cons: - domU depends on files outside of its disc-image, so you >> have to keep an eye of what domU uses what kernel-file >> - on upgrading the domU-kernel is a bit more complicated, keep >> kernel, maybe existing initrd and modules-directory in sync >> >> - domU-kernel placed inside the domU-diskimage. Works for both HVM and >> paravirt-domU. One sees mostly this nowadays. Kernel is located/booted >> by pygrub (or a script mounting the partition, making a copy of the >> kernel inside to dom0, and starting it then) >> pros: - easy updating, i.e. just ''yum update'' from the domU updates >> the >> kernel, initrd, modules and kernel is booted on next domU-boot > > > You forgot the con. > > cons: Security. You now have a domU in which a local exploit could > result in code being executed in dom0 at the next boot of that domU. > By the way, this actually happened. See CVE-2007-4993 > > IMHO putting the kernel in domU and using pygrub was always asking for > trouble. > > In my opinion it is completely crazy to expose dom0 to potential > exploits from domU. > > So far as I am aware this is the *only* way to so expose dom0 to domU > security holes and I am deeply shocked if it is true that "One sees > mostly this nowadays" >There''s a big advantage to pygrub: kernel update procedures for DomU have nothing to do with Dom0''s kernel. This prevents version and feature conflicts with package management sytems, and allows updates and reboots of DomU without having to write to Dom0. This was particularly troublesome with the Xensource kernels for RHEL 4 and RHEL 5, which had such different versions for kernel-xen on the server and kernel-xenU on the guest that it made RHEL whine quite hard about the Dom0 getting such an old kernel installed on it. And if you tried to use kernel-xen on the DomU, it created conflicts because the RHEL 4 kernel and RHEL 5 kernels had the same names and file names, and it could screw up which kernel you wound up with. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
CentOS didn''t do this! RedHat did it this way, CentOS is a rebuild of RHEL. IDAGroup - R.W.Muller wrote:> Wow, if that is true then is CentOS making a big mistake. > When I installed CentOS with virtualization and started virt-install > according to there howto, I was guided to install another CentOS domU > but never asked to have a kernel outside the domU. > > So, I just even realized that this is possible, when I was reading > this user list, before I thought the CentOS way is the only > possibility ...so clearly: kernel IN domU > > Steve Wray wrote: >> Christian Horn wrote: >>> On Fri, Oct 12, 2007 at 12:14:02AM -0400, IDAGroup - R.W.Muller wrote: >>>> Hi, I found lots of threads where people talk about domU kernel >>>> sitting in /boot of dom0. >>>> The only kernel I can see there is the one the machine and dom0 >>>> booted from (vmlinuz-2.6.18-8.el5xen) >>> >>> Two places are common: >>> - domU-kernel placed on dom0-filesystem directly, ''kernel'' option in >>> xen- >>> config for the domU is used then. Only possible for paravirt-domU. >>> pros: - kernel is directly reachable from dom0 >>> cons: - domU depends on files outside of its disc-image, so you >>> have to keep an eye of what domU uses what kernel-file >>> - on upgrading the domU-kernel is a bit more complicated, keep >>> kernel, maybe existing initrd and modules-directory in sync >>> >>> - domU-kernel placed inside the domU-diskimage. Works for both HVM and >>> paravirt-domU. One sees mostly this nowadays. Kernel is >>> located/booted >>> by pygrub (or a script mounting the partition, making a copy of the >>> kernel inside to dom0, and starting it then) >>> pros: - easy updating, i.e. just ''yum update'' from the domU >>> updates the >>> kernel, initrd, modules and kernel is booted on next >>> domU-boot >> >> >> You forgot the con. >> >> cons: Security. You now have a domU in which a local exploit could >> result in code being executed in dom0 at the next boot of that domU. >> By the way, this actually happened. See CVE-2007-4993 >> >> IMHO putting the kernel in domU and using pygrub was always asking >> for trouble. >> >> In my opinion it is completely crazy to expose dom0 to potential >> exploits from domU. >> >> So far as I am aware this is the *only* way to so expose dom0 to domU >> security holes and I am deeply shocked if it is true that "One sees >> mostly this nowadays" >> >> >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users >> > ------------------------------------------------------------------------ > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi Nico,> There''s a big advantage to pygrub: kernel update procedures for DomU have > nothing to do with Dom0''s kernel. This prevents version and feature > conflicts with package management sytems, and allows updates and reboots > of DomU without having to write to Dom0.I like it the other way round: I do one kernel-update in Dom0 and all my virtual machines profit by a simple DomU reboot. My VMs have no kernel and no modules, so there is one source of error less for DomU-admins. No kernel manipulations, no root-kits.> This was particularly troublesome with the Xensource kernels for RHEL 4 > and RHEL 5, which had such different versions for kernel-xen on the > server and kernel-xenU on the guest that it made RHEL whine quite hard > about the Dom0 getting such an old kernel installed on it. And if you > tried to use kernel-xen on the DomU, it created conflicts because the > RHEL 4 kernel and RHEL 5 kernels had the same names and file names, and > it could screw up which kernel you wound up with.This is a Redhat problem, evil, and not a reason to use pygrub. Gruß, cp _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Christoph Purrucker wrote:> Hi Nico, > > >> There''s a big advantage to pygrub: kernel update procedures for DomU have >> nothing to do with Dom0''s kernel. This prevents version and feature >> conflicts with package management sytems, and allows updates and reboots >> of DomU without having to write to Dom0. >> > > I like it the other way round: I do one kernel-update in Dom0 and all my > virtual machines profit by a simple DomU reboot. My VMs have no kernel and > no modules, so there is one source of error less for DomU-admins. No > kernel manipulations, no root-kits. >It doesn''t work with RHEL 4 guest domains on a RHEL 5 server. You can''t install the kernel-xenU on the RHEL 5 server without putting in override commands, and *that* causes compatibility whinging when you try to update kernel-xen. And then you have to go hand-edit the DomU config files, unless you''re using the symlink based names for the kernel, and *that* is sensitive to which kernel you installed last. Not having modules in the DomU''s means that you can''t do FUSE based file-system mounting in your DomU''s, mount NTFS partitions, or do other useful tricks, unless you go to the extra pain of hand-building and hard-loading *all* the necessary modules on your Dom0 in order to have entirely consistent DomU''s. Man, that''s a lot of work! And you can''t run DomU''s with different kernels without extra management steps.>> This was particularly troublesome with the Xensource kernels for RHEL 4 >> and RHEL 5, which had such different versions for kernel-xen on the >> server and kernel-xenU on the guest that it made RHEL whine quite hard >> about the Dom0 getting such an old kernel installed on it. And if you >> tried to use kernel-xen on the DomU, it created conflicts because the >> RHEL 4 kernel and RHEL 5 kernels had the same names and file names, and >> it could screw up which kernel you wound up with. >> > > This is a Redhat problem, evil, and not a reason to use pygrub. > > Gruß, > cp >No, it''s an RPM problem. It''s inherent in management systems that correctly detect version incompatibilities, and don''t expect you to install software components on your Dom0 that are only there for DomU''s, not for local use. It''s even worse if you have a 64-bit Dom0 and 32-bit DomU''s!!! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, Oct 14, 2007 at 08:49:19PM -0400, IDAGroup - R.W.Muller wrote:> Wow, if that is true then is CentOS making a big mistake.Nah, they probably took the pros and cons into account and then made the same decision as suse did for SLES: put it all into the discfile. Xen needs a bit more work than vmware, and this is a step to make the handling of domUs simpler.> Steve Wray wrote: > > > >You forgot the con. > > > >cons: Security. You now have a domU in which a local exploit could > >result in code being executed in dom0 at the next boot of that domU. > >By the way, this actually happened. See CVE-2007-4993Right, its a con. Just couldnt think of at the time of writing ;) Christian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nico Kadel-Garcia wrote:> Steve Wray wrote: >> Christian Horn wrote: >>> On Fri, Oct 12, 2007 at 12:14:02AM -0400, IDAGroup - R.W.Muller wrote: >>>> Hi, I found lots of threads where people talk about domU kernel >>>> sitting in /boot of dom0.[snip]>> >> cons: Security. You now have a domU in which a local exploit could >> result in code being executed in dom0 at the next boot of that domU. >> By the way, this actually happened. See CVE-2007-4993 >> >> IMHO putting the kernel in domU and using pygrub was always asking for >> trouble. >> >> In my opinion it is completely crazy to expose dom0 to potential >> exploits from domU. >> >> So far as I am aware this is the *only* way to so expose dom0 to domU >> security holes and I am deeply shocked if it is true that "One sees >> mostly this nowadays" >> > There''s a big advantage to pygrub: kernel update procedures for DomU > have nothing to do with Dom0''s kernel. This prevents version and feature > conflicts with package management sytems, and allows updates and reboots > of DomU without having to write to Dom0. This was particularlyI don''t believe that the convenience of this outweighs the undeniable security implications. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
It''s funny, my test installation just got hacked. I had a idiot password for domU and somebody uploaded a suKit 1.3 and I also found trace of adding a user (www) in dom0 and trying to change pathes with PATH=:.: plus doing an FTP connection from dom0 (history of root in dom0, showed "ftp hackers.home.domain"). Ok I can confirm, that dom0 can be exposed to hacking by putting the kernel into domU. Now the big question is: how can I install a Centos domU on Centos dom0 and have the kernel OUTSIDE domU ? ..and has already somebody installed xen-shell on Centos 5 dom0 ? Thanks, Robin Christian Horn wrote:> On Sun, Oct 14, 2007 at 08:49:19PM -0400, IDAGroup - R.W.Muller wrote: > >> Wow, if that is true then is CentOS making a big mistake. >> > > Nah, they probably took the pros and cons into account and then made > the same decision as suse did for SLES: put it all into the discfile. > Xen needs a bit more work than vmware, and this is a step to make the > handling of domUs simpler. > > >> Steve Wray wrote: >> >>> You forgot the con. >>> >>> cons: Security. You now have a domU in which a local exploit could >>> result in code being executed in dom0 at the next boot of that domU. >>> By the way, this actually happened. See CVE-2007-4993 >>> > Right, its a con. Just couldnt think of at the time of writing ;) > > > Christian > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Reading this thread i realise i have a problem in hand which is somehow related. I was running xen packages on centos and created a domU. First i was surprised to see pygrub in the config file, although i ignored it since it worked out of the box. Now because of a problem with the raid card drivers, i had to hand compile xen from source, and now i cannot boot the domU instance :( Any clues on how it can be done ? -- regards, Anand Gupta _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users