On jeu., 2011-01-27 at 22:21 +0000, Ian Campbell wrote: > > I was assuming people wanting a grsec kernel would prefer having UDEREF > > than XEN, but we might as well use the more conservative approach and > > keep XEN enabled (and UDEREF disabled) and wait for feedback from users. > > If bugreports are reported asking for UDEREF we can still revisite that > > later. > > Can you describe how it works and what makes it slow for Xen? UDEREF tries to prevent the kernel to dereference pointers to userland by tuning the segmentation model, modifying the global descriptor table and the various functions copying from/to userspace. If Xen (or another hypervisor) has assumptions about the segment layouts, then those assumptions will break on a grsec kernel. You can find more information there: http://grsecurity.net/~spender/uderef.txt (and the amd64 announcement there http://grsecurity.net/pipermail/grsecurity/2010-April/001024.html) > > It sounds like strictly speaking it's not "broken" under Xen as such, > it's just not recommended since it is effectively unusable with certain > guest types. It's not clear if the comment is referring to PV guests or > HVM guests using shadow mode. i.e. It's not clear if "hardware > virtualization support" refers to HVM generally or more specifically to > HAP (hardware assisted paging). > > The problem with disabling CONFIG_XEN in this way is that it will also > disable the Xen PVHVM drivers which enhance disk and network performance > for HVM guests. > > Hardware with HVM is really quite common these days and HAP has been > around for quite a while too so it's not as rare as the comment makes > out. > > I think that if we are going to have this flavour then it should have > both Xen and grsec. That allows it to work for people using HVM (+/- HAP > as discussed above) guests. For people with PV guests they can either > choose dog-slow-but-secure or fast. Maybe that's not much of a > choice ;-) > I've tried to build a kernel with CONFIG_XEN and CONFIG_PAX_UDEREF. Build succeeds and it boots fine, but I don't have a working xen setup to try it (wether on host or on guest). I've tried to run a kvm guest (using a standard kernel) and it's slow as hell, but it was the same without CONFIG_XEN. It'd be worth trying on i386 though. I can provide you that kernel if you want to try yourself (or only the edited patch removing the conflict against CONFIG_XEN, though it's trivial to do). Regards, -- Yves-Alexis Perez ANSSI/ACE/LAM
Attachment:
signature.asc
Description: This is a digitally signed message part