Hi, I''m struggling for more than a week now, to build a 2.6.22.18 vanilla kernel with xen support. I''ve read all the information sources related to this issue that I have found, and still no solution for this (theoretically) simple issue. Can someone please point me into the right direction ? I''m really stuck . -- ==================================== inf. Manuel SUBREDU Senior SysAdm Phone: +40 (232) 201007 Email: manuel.subredu roedu net ==================================== _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Feb 26, 2008 at 07:39:54PM +0200, Subredu Manuel wrote:> > Hi, > > I''m struggling for more than a week now, to build a 2.6.22.18 vanilla > kernel with xen support. I''ve read all the information sources related > to this issue that I have found, and still no solution for this > (theoretically) simple issue. > Can someone please point me into the right direction ? I''m really stuck . >Official Xen releases contain Xenlinux patches only for Linux 2.6.18 kernel. Some distributions have forward ported these patches to newer kernels, but they tend to have more bugs and less testing.. So I''d recommend you to use the official 2.6.18 kernels. .. Or wait for Redhat (and others) to finish Xen pvops support and get it integrated to vanilla Linus kernel.org kernels.. This work should appear in Fedora 9 kernel this spring. After that Xen support should be in every Linux release automatically. -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 26 Feb 2008, Pasi Kärkkäinen wrote:> On Tue, Feb 26, 2008 at 07:39:54PM +0200, Subredu Manuel wrote: >> >> Hi, >> >> I''m struggling for more than a week now, to build a 2.6.22.18 vanilla >> kernel with xen support. I''ve read all the information sources related >> to this issue that I have found, and still no solution for this >> (theoretically) simple issue. >> Can someone please point me into the right direction ? I''m really stuck . >> > > Official Xen releases contain Xenlinux patches only for Linux 2.6.18 kernel. > > Some distributions have forward ported these patches to newer kernels, but > they tend to have more bugs and less testing.. > > So I''d recommend you to use the official 2.6.18 kernels.I can not agree with that. If you''re messing around on your desktop machine, ok... you''ve already got root and you are the only user... security patches aren''t important in that scenario ... but if you''re providing real services to real users, and you don''t want some script kiddie wiping out your box starting from a PHP or SQL injection exploit, then you need to be using kernels that aren''t 18 months out of date. Unfortunately, xensource doesn''t really seem to be interested in making building easy, or even in packaging things anymore :( Personally, I''d like to see someone fork the project so that we can get a system that''s easier to build and works against a more current kernel... but I don''t have the time :( -Tom _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 26 Feb 2008, Tom Brown wrote:> On Tue, 26 Feb 2008, Pasi Kärkkäinen wrote: > >> On Tue, Feb 26, 2008 at 07:39:54PM +0200, Subredu Manuel wrote: >> > >> > Hi, >> > >> > I''m struggling for more than a week now, to build a 2.6.22.18 vanilla >> > kernel with xen support. I''ve read all the information sources related >> > to this issue that I have found, and still no solution for this >> > (theoretically) simple issue. >> > Can someone please point me into the right direction ? I''m really stuck >> > . >> > >> >> Official Xen releases contain Xenlinux patches only for Linux 2.6.18 >> kernel. >> >> Some distributions have forward ported these patches to newer kernels, but >> they tend to have more bugs and less testing.. >> >> So I''d recommend you to use the official 2.6.18 kernels. > > I can not agree with that. If you''re messing around on your desktop machine, > ok... you''ve already got root and you are the only user... security patches > aren''t important in that scenario ... but if you''re providing real services > to real users, and you don''t want some script kiddie wiping out your box > starting from a PHP or SQL injection exploit, then you need to be using > kernels that aren''t 18 months out of date.Sorry, even that isn''t very well written... Most linux security patches are for local exploits (priveledge escalation), and these aren''t very relevent if you are the only user and you already have root :) I''m not aware of any recent remote exploits against the linux kernel. If there were then the above generalization is out to lunch. -Tom _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tuesday 26 February 2008 16:54:42 Tom Brown wrote:> On Tue, 26 Feb 2008, Tom Brown wrote: > > On Tue, 26 Feb 2008, Pasi Kärkkäinen wrote: > > > > I can not agree with that. If you''re messing around on your desktop > > machine, ok... you''ve already got root and you are the only user... > > security patches aren''t important in that scenario ... but if you''re > > providing real services to real users, and you don''t want some script > > kiddie wiping out your box starting from a PHP or SQL injection exploit, > > then you need to be using kernels that aren''t 18 months out of date.Humm... SQL Injections don''t has any issue with kernels and the PHP fails normally runs with low level privileges on system, it could... but it''s not likely to hit the kernel without huge efforts. But I think the worst thing here is not a security problem, even 2.6.18 had security patches for the recent fails (all locals like you said bellow). I believe the linux kernel is very solid in security. The most complex thing in stay in a too old version is lack of some usefull (or necessary) resource only present in a more new version like the new wireless drivers, new netfilter capabilities, etc. I have a issue with a driver for Marvell IDE with the 2.6.18. Luck me a workaround with the generic IDE save my life, but remember that not always we have this stuffs on hand. even in a desktop you will find this issues. Another problem is patch the kernel with more than one "no offcial" modification like RSBAC, GRSecurity, maybe ReiseFS4 or other stuffs like, because them conflicts for alter the same files. The PaX patch for example give me so headaches with Xen and I abandon the ideia. To many *RE*code for me yet. If the Xen is part of vanilla, the other unofficials will do patchs considering it by default. This is more likely to happen in a server. The older nVidia proprietary driver hangs the X.org up because it wasn''t "xen aware" (i believe that there is others issues actually). Of course this is not a kernel bug, it''s a nVidia driver problem. But if the official kernel could had the Xen, this things won''t occour anymore, because problably, the nVidia driver makers will test it in a vanilla kernel at best, but with native Xen inside it. ;-) I dislikes the patches for OpenSuse, fedora and others because its not very tested like the official 2.6.18, and I use Xen in production! The lack of a complete and centralized documentation turn it very hard to undestand the Xen without some deep hacking, even "only do it function" can be trickery. So I don''t need a less tested, no official patch that come in newer versions to complicate it more. Last, if you have hvm (Have you more cash to expend? :-) ) you can export some PCI bus to the VM and use a very recent kernel there to deal with the hardware, or try the 2.6.2[34].x with domU in Para VIrtualization. This could bring some useful things in hand to manipulate some of the issues I talked, but not all. In the dom0, I suggest to stay in 2.6.18.x for now.> Sorry, even that isn''t very well written... Most linux security patches > are for local exploits (priveledge escalation), and these aren''t very > relevent if you are the only user and you already have root :) > > I''m not aware of any recent remote exploits against the linux kernel. If > there were then the above generalization is out to lunch. > > -TomVery old times, I remembered of tear drops, and some floods TCP techniques capable to hangs the kernel :-). If my memory is not wrong some netfilter code has failed to manipulate some TCP/IP headers and could be exploited. And again, recently the most recent remote exploits targets user space high level protocols or exploiting bad writed web application not the kernel. Douglas _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 26 Feb 2008, Valter Douglas Lisbôa Jr. wrote:> On Tuesday 26 February 2008 16:54:42 Tom Brown wrote: >> On Tue, 26 Feb 2008, Tom Brown wrote: >>> On Tue, 26 Feb 2008, Pasi Kärkkäinen wrote: >>> >>> I can not agree with that. If you''re messing around on your desktop >>> machine, ok... you''ve already got root and you are the only user... >>> security patches aren''t important in that scenario ... but if you''re >>> providing real services to real users, and you don''t want some script >>> kiddie wiping out your box starting from a PHP or SQL injection exploit, >>> then you need to be using kernels that aren''t 18 months out of date. > Humm... SQL Injections don''t has any issue with kernels and the PHP fails > normally runs with low level privileges on system, it could... but it''s not > likely to hit the kernel without huge efforts.wtf? There are thousands of crappy php scripts out there that can be tricked into running arbitrary code ... add any one of the priviledge escalation vulnerabilities and the attacker can escalate "arbitrary code" into "root access". _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tuesday 26 February 2008 20:18:42 Tom Brown wrote:> On Tue, 26 Feb 2008, Valter Douglas Lisbôa Jr. wrote: > > On Tuesday 26 February 2008 16:54:42 Tom Brown wrote: > >> On Tue, 26 Feb 2008, Tom Brown wrote: > >>> On Tue, 26 Feb 2008, Pasi Kärkkäinen wrote: > >>> > >>> I can not agree with that. If you''re messing around on your desktop > >>> machine, ok... you''ve already got root and you are the only user... > >>> security patches aren''t important in that scenario ... but if you''re > >>> providing real services to real users, and you don''t want some script > >>> kiddie wiping out your box starting from a PHP or SQL injection > >>> exploit, then you need to be using kernels that aren''t 18 months out of > >>> date. > > > > Humm... SQL Injections don''t has any issue with kernels and the PHP fails > > normally runs with low level privileges on system, it could... but it''s > > not likely to hit the kernel without huge efforts. > > wtf?My english is not so good, what this mean :-)> There are thousands of crappy php scripts out there that can be > tricked into running arbitrary code ... > add any one of the priviledge > escalation vulnerabilities and the attacker can escalate "arbitrary code" > into "root access".Yes, but do it is not so easy. If it be true, we has been gain a tons of exploits daily. Find a security fail, is a thing, reveals it to the world is other, do a real working exploit useable fo anyone is another yet. :-) I wasn''t say it cannot be do, and is our obligation actualize the system (of course it is), but do a real penetrating in a system from a "bad input handle in PHP" to "execute a shell code in the system to be root" is hard, take time and require skill. A wanabee invasor is not likely to hack through a system without many working tools (read many just on hand exploits). Do it by raw force (read this find the fail, create a way to exploit it, make the shell code, etc.) is quite rare (for good or for bad). The most security fails showed in the Internet lacks the tool of proof part and is simple announced. Note I not want to say that we can ignore security fails! We need maintain a upgraded system in any level. From high level to kernel. What I mean - is script kiddies cannot do it so easy. Coming back to the thread, any security issue in the kernel 2.6.18.x had a correction, official or not. Some of them was posted in Xen-Devel list in a couple of days back. Again, the most problems I see/find in stay in 2.6.18.x is the lack of drivers for recent hardware and some newer kernel resources. It''s a very stable branch, the only major bug that throuble me is old AMD+PCChips hardware (no way to do it function!) Finally, I will be very happy if Xen become offcially inside the vanilla kernel too. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Feb 26, 2008 at 11:38:29AM -0800, Tom Brown wrote:> On Tue, 26 Feb 2008, Pasi Kärkkäinen wrote: > > >On Tue, Feb 26, 2008 at 07:39:54PM +0200, Subredu Manuel wrote: > >> > >> Hi, > >> > >> I''m struggling for more than a week now, to build a 2.6.22.18 vanilla > >>kernel with xen support. I''ve read all the information sources related > >>to this issue that I have found, and still no solution for this > >>(theoretically) simple issue. > >> Can someone please point me into the right direction ? I''m really stuck . > >> > > > >Official Xen releases contain Xenlinux patches only for Linux 2.6.18 > >kernel. > > > >Some distributions have forward ported these patches to newer kernels, but > >they tend to have more bugs and less testing.. > > > >So I''d recommend you to use the official 2.6.18 kernels. > > I can not agree with that. If you''re messing around on your desktop > machine, ok... you''ve already got root and you are the only user... > security patches aren''t important in that scenario ... but if you''re > providing real services to real users, and you don''t want some script > kiddie wiping out your box starting from a PHP or SQL injection exploit, > then you need to be using kernels that aren''t 18 months out of date. >2.6.18.8 is released 02/24/2007.. so just 12 months old :) Other option is to use vendor supported kernels, for example RHEL5 and CentOS5 (xen) kernels are based on 2.6.18 with all the security fixes and patches included (back ported). -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>>>> then you need to be using kernels that aren''t 18 months out of date. >> Humm... SQL Injections don''t has any issue with kernels and the PHP fails >> normally runs with low level privileges on system, it could... but >> it''s not >> likely to hit the kernel without huge efforts. > > wtf? There are thousands of crappy php scripts out there that can be > tricked into running arbitrary code ... add any one of the priviledge > escalation vulnerabilities and the attacker can escalate "arbitrary > code" into "root access".Indeed, we all have to keep our systems secure, but this doesn''t necessarily means that we need to keep the latest bleeding-edge kernel version running. I agree with you, that it IS possible to escalate privileges even with dumb php scripts, but I disagree that newer kernel versions are tha best way to fix those issues. btw. I also found xensource''s 2.6.18.8-xen *much* more stable than any xenified kernel on 32bit as well as on 64bit. for newer drivers a backport is always possible. Stephan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, Feb 27, 2008 at 03:04:50PM +0100, Stephan Seitz wrote:> > >>>>then you need to be using kernels that aren''t 18 months out of date. > >>Humm... SQL Injections don''t has any issue with kernels and the PHP fails > >>normally runs with low level privileges on system, it could... but > >>it''s not > >>likely to hit the kernel without huge efforts. > > > >wtf? There are thousands of crappy php scripts out there that can be > >tricked into running arbitrary code ... add any one of the priviledge > >escalation vulnerabilities and the attacker can escalate "arbitrary > >code" into "root access". > > Indeed, we all have to keep our systems secure, but this doesn''t necessarily > means that we need to keep the latest bleeding-edge kernel version running. > > I agree with you, that it IS possible to escalate privileges even with dumb > php scripts, but I disagree that newer kernel versions are tha best way to > fix those issues. > > btw. I also found xensource''s 2.6.18.8-xen *much* more stable than any > xenified > kernel on 32bit as well as on 64bit. >Yes, 2.6.18 based Xen (Xenlinux) kernels are the most stable at the moment, and support all the features Xen has. Xen (pvops) support found in 2.6.2x kernels is far from complete.. at the moment it lacks at least: - dom0 support - 64b support - live migration - testing and stability So it basicly only works for PV domU. This is going to change hopefully soon when Redhat guys finish the pvops dom0 and x86-64 support.. and get it integrated into mainline Linux kernels.> for newer drivers a backport is always possible. >Yes, Redhat and Novell are doing exactly this. They''re backporting driver fixes/patches and even features to 2.6.18 or 2.6.16 kernels. -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users