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

[Xen-devel] ASM Help Requested

  • To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "John Anderson" <johnha@xxxxxxxxxx>
  • Date: Wed, 28 Jun 2006 09:53:18 -0700
  • Delivery-date: Wed, 28 Jun 2006 09:53:50 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acaa01sCxFKXnZpzTHyRoMygzvSj0Q==
  • Thread-topic: ASM Help Requested

I’m a big fan of the GRSecurity/PAX project [ http://www.grsecurity.org ], and I’d like to be able to use GRSecurity and PAX with Xen.  The only way to do that was to test out GRSec patched kernels on VT hardware using HVM guests.  I got to thinking it was kind of a waste of resources to fully virtualize Linux on Xen just to use GRSecurity.  I began porting GRSecurity/PAX to the XenLinux kernel.  Now that port is about 90% complete and it currently looks like arch-X86_64 is completely working for both Dom0 and DomU’s.  That brings me to my problem with arch-i386.  I’ve got the i386-xen-grsec kernel to compile cleanly, but it crashes on Dom0 boot.  The reason X86_64 is working already is because GRSec nor PAX has a need to touch arch/x86_64/kernel/{head-xen.S,entry-xen.S}.  However, it does need to modify arch/i386/{head-xen.S,entry-xen.S}.  The reason it needs to modify this file is because patching a kernel with GRSec eliminates the per_cpu(cpu_gdt_descr, cpu) call and replaces it with an array of cpu_gdt_descr in the exact same manner that works for X86_64.  arch/x86_64/kernel/head-xen.S already defines and populates cpu_gdt_descr and cpu_gdt_table as GRSec expects them to be, but arch/i386/kernel/head-xen.S does not. 


On a vanilla kernel the GRSecurity patch will patch arch/i386/kernel/{head.S,entry.S} to add support for this array of cpu_gdt_descr and also adds code for PAX_KERNEXEC.  Since the –xen versions of these .S files differ greatly from the vanilla kernel versions of these .S  files the GRSec patch does “port over” at all.  I don’t understand what this code is doing well enough to properly make the changes.  However, these two files, I think, are the only obstacle remaining before a GRSec port for Xen is functional.  Maybe not stable, but at least testable! J


If there is anyone who understands the ASM of head-xen.S & entry-xen.S well enough to give this shot, please let me know.  I’ll be of whatever assistance I can.



How to get and use the port of GRSecurity for Xen, broken i386 ASM and all:


The patches below apply to xen-3.0-testing (currently Xen-3.0.2-3) [ http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-3.0-testing-src.tgz ]


This patch applies to the linux-2.6-xen-sparse directory. [ http://chesty.homedns.org:4572/grsecurity-2.1.9-xen-3.0-testing.patch ]

Copy this patch into patches/   [ http://chesty.homedns.org:4572/z_grsecurity-2.1.9-xen-3.0.2t.patch ]


The GRSecurity patch the port is based on ( for references on what exactly GRSec is trying to do arch/i386/kernel/{head.S,entry.S}

[ http://forums.grsecurity.net/~spender/grsecurity-2.1.9- ]


The patches from chesty.homedns.org are currently hosted off my box at home.  If there are any connectivity issues or anything, please email me and I’ll yell at my ISP.


Other Links:


GRSecurity development forum thread about this port:



Thank you,


John Anderson
Sr. Systems Administrator



Xen-devel mailing list



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