On Wed, 2011-01-26 at 13:29 +0100, Yves-Alexis Perez wrote: > > config PAX_MEMORY_UDEREF > bool "Prevent invalid userland pointer dereference" > depends on X86 && !UML_X86 && !XEN > select PAX_PER_CPU_PGD if X86_64 > help > By saying Y here the kernel will be prevented from dereferencing > userland pointers in contexts where the kernel expects only kernel > pointers. This is both a useful runtime debugging feature and a > security measure that prevents exploiting a class of kernel bugs. > > The tradeoff is that some virtualization solutions may experience > a huge slowdown and therefore you should not enable this feature > for kernels meant to run in such environments. Whether a given VM > solution is affected or not is best determined by simply trying it > out, the performance impact will be obvious right on boot as this > mechanism engages from very early on. A good rule of thumb is that > VMs running on CPUs without hardware virtualization support (i.e., > the majority of IA-32 CPUs) will likely experience the slowdown. > > > 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? 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 ;-) Ian. -- Ian Campbell Be free and open and breezy! Enjoy! Things won't get any better so get used to it.
Attachment:
signature.asc
Description: This is a digitally signed message part