Re: Enable PAGEEXEC as default? (WAS: Re: [gentoo-hardened] Grsecurity slows down a web server?)

[Gordon Malm]

On Saturday, January 24, 2009 00:06:25 David Sommerseth wrote:
> René Rhéaume wrote:
> > On Fri, Jan 23, 2009 at 11:45 AM, Grant <emailgrant@×××××.com> wrote:
> >> Very close.  PAGEEXEC is enabled, but so is SEGMEXEC.  My CPU is a
> >> P4-2.8, and I'm not sure about NX support but these are the flags:
> >>
> >> fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36
> >> clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts
> >> pni monitor ds_cpl cid xtpr
> >
> > There is no "nx" in your cpuinfo flags. Therefore, your P4 does not
> > have the hardware NX bit (or XD bit in Intel wording)
>
> Hi all!
>
> I've been following this discussion a little bit.  I do have a Pentium D
> processor which do have the "nx" flag available.
>
> I see I do have CONFIG_PAX_PAGEEXEC=y in the kernel config, but I do also
> see that all non-kernel processes do have peMRS in the PAX flags when
> checking with the pspax command.
>
> Should I strive to get the PAGEEXEC flag set on all processes, or should I
> not?
>
> Another thing ... I do not quite understand why processes are listed with
> peMRS when paxctl says something a little bit different.  An example:
>
> pspax:
> root     11864  peMRS  w^x  ET_EXEC    openvpn          =ep cap_setpcap-ep
>
> paxctl -v /usr/sbin/openvpn:
> - PaX flags: -------x-e-- [/usr/sbin/openvpn]
> 	RANDEXEC is disabled
> 	EMUTRAMP is disabled
>
> I've scanned through the whole system with "qlist -ao|scanelf -f - -q -x"
> and can't say I find anything here which is of concern, it only finds
> those paxtest files in /usr/lib/paxtest ... so everything should be
> default on the file level.
>
> I was of that understanding that my current setup would give PAGEEXEC as
> default.
>
>
> kind regards,
>
> David Sommerseth

When you enable both SEGMEXEC and PAGEEXEC on IA32, modern PaX will use 
PAGEEXEC if nx bit is accessable and fall back to SEGMEXEC if it is not.  
This is why both can be enabled safely, even on old P4's without and NX bit.  
When you 'cat /proc/cpuinfo', it is showing you the processor's capability, 
but that doesn't mean the NX bit is accessible.  To make the NX bit 
accessible you need to enable PAE.  You can do this by choosing NOHIGHMEM+PAE 
or HIGHMEM64G (which selects PAE automatically) in your kernel config.

Re:
PaX flags: -------x-e-- [/usr/sbin/openvpn]

What this means is you are leaving PaX to act on its default behavior 
according to how it is configured in the kernel, with the exception of 
RANDEXEC and EMUTRAMP which have been explicitly disabled.

The peMRS shows you that PAGEEXEC and EMUTRAMP are not in effect for this 
process, but SEGMEXEC, MPROTECT and ASLR are.

http://www.bumpin.org/pics/PaX/pax_performance-2.6.24.png
(Note: The easiest way to interpret this chart is to ignore the figures for 
NoNX/NOEXEC=y and NX/NOEXEC=y - these were academic tests more than anything 
and are rather meaningless)

As you can see PAGEEXEC with an NX bit does have a very minor speed advantage 
over SEGMEXEC.  PAGEEXEC also has the advantage of not cutting a processes' 
address space in half.  Without an NX bit available, PAGEEXEC is a fair hit 
on IA32.  Pentium 4's without an NX bit take an even larger hit:

http://www.pjvenda.org/linux/doc/pax-performance/

That the P4's result would be very different from other's is not surprising.  
It utilizes the very different Netburst microarchitecture and has a 20-31 (31 
on Prescott and Cedar Mill) stage pipeline. Compare this to 10 for the P3, 14 
for the Core2, 12 for the Athlon64, 10 for the AthlonXP, etc. you get the 
picture.

So if you have an NX bit, yes, use it.  If you don't, SEGMEXEC is a good 
alternative.  It is safe to enable both options, PaX is smart enough to 
choose between the two.

Gordon Malm (gengor)