Just thought I&#39;d share some notes with pax &amp; lguest (so if anyone else is looking for information, they can hopefully stumble across it).<br><br>short version:<br>PAGEEXEC = for hosts with PAE = works.<br>SEGMEXEC = for guests = works. (PAGEEXEC = no work).<br>
UDEREF = works with no slow down.<br>KERNEXEC = does not work due to limitations. maybe possible to make work for some extra protection<br>Documentation/lguest/lguest.c = needs a minor tweak to avoid paxctl -m.<br><br>tl;dr version:<br>

<br>First off, <a href="http://swtch.com/lguest/">http://swtch.com/lguest/</a> for information about it. My config file is at <a href="http://www.pastebin.ca/1978595">http://www.pastebin.ca/1978595</a>. Host is a Atom N270, no hw virtualisation. kernel config is pretty full on; it&#39;s mostly just a ubuntu .config file with some things tweaked, with no trimming down. atom processors seem to be popular with green hosting / netbook laptops.<br>
<br>Mostly good news, lguest works using PAGEEXEC for the host, and SEGMEXEC for the guests (lguest does not support NX bit, as documented in arch/x86/lguest/boot.c, so it falls back.) UDEREF works from what I can tell.<br>
<br>Commenting out the line that disables NX bit and recompiling makes it use page exec, but paxtest exec tests fail. It would be ideal if lguest supported NX bit. I have not looked at why this is the case, or how easy it would be to implement it.<br>
<br>KERNEXEC seems like it would be unsupported; as lguest wants to map executable code at 0xff[ce]00000 (drivers/lguest/core.c). I know for certain it does not work if you enable kernel modules :-) It would be nice if it was supported for the host. From looking at free_initmem(), it won&#39;t be supported if it is being paravirt&#39;d. <br>
<br>A random thought is that by tweaking KERNEXEC to prevent userland access (yet allow full kernel) and relying on PAE+NX (to protect kernel pages) will give you at least something on the host kernel while allowing lguest to work. that said, it could be argued that having that mapped in memory at a fixed location is a bad idea.<br>
<br>lguest userland (Documentation/lguest/lguest.c) requires some work to get it suitable. sed -ie &#39;s/|PROT_EXEC//g&#39; and it will work fine on the host. Additionally, adding a chroot/chdir/setgroups/setresgid/setresuid just before run_guest() seems to work fine (of course, it will break rebooting which execv&#39;s itself ... unless it is statically compiled, and file permissions / /dev/net/tun is fine). <br>
<br>Another interesting lguest.c thing is that it looks like it could work well with seccomp -- once you tweak seccomp to allow pread/pwrite/readv/writev -- though i suspect the only person interested in that would be me. ;)<br>
<br>and that&#39;s about it :-) all in all lguest seems pretty decent and friendly towards pax/grsecurity :)<br>