grsecurity forums

Hi,

After patching my kernel with the 2.0-pre3 patch against 2.4.20, I ran an apt-get upgrade in debian, and noticed a severe degredation in performance.

The extraction of the packages took about 5x or more times what it usually takes, and the building of the package list took significantly longer.

So I ran an hdparm, and lo and behold:

/dev/hda:
Timing buffer-cache reads: 128 MB in 3.72 seconds = 34.41 MB/sec
Timing buffered disk reads: 64 MB in 3.56 seconds = 17.98 MB/sec
Hmm.. suspicious results: probably not enough free memory for a proper test.

This is a Pentium 3 1Ghz Coppermine with PC133 RAM. The buffered disk reads are about right, but the buffer-cache reads (an indicator of memory performance iirc) is typicall 120MB/s or so.

So is it normal for the grsecurity patch to impact the performance of the box this much? I compiled the kernel with grsecurty mode 'high' (no customizations).

here are the relevant gr security .config options:

CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MID is not set
CONFIG_GRKERNSEC_HI=y
# CONFIG_GRKERNSEC_CUSTOM is not set
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=4
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_RANDPID=y
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
CONFIG_GRKERNSEC_RANDPING=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=10
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
# CONFIG_GRKERNSEC_AUDIT_MOUNT is not set
# CONFIG_GRKERNSEC_ACL_HIDEKERN is not set
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PAX_NOEXEC=y
# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
CONFIG_GRKERNSEC_PAX_MPROTECT=y
# CONFIG_GRKERNSEC_PAX_ETEXECRELOCS is not set
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDEXEC=y
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
# CONFIG_GRKERNSEC_PAX_EMUTRAMP is not set
# CONFIG_GRKERNSEC_PAX_EMUSIGRT is not set
CONFIG_GRKERNSEC_AUDIT_MOUNT=y

Thanks in advance!

hi,

/edit:

most likely NOEXEC causes the load and slows down system. try turning it off and then see if it helps.

Mikhail.

pfloyd wrote:So is it normal for the grsecurity patch to impact the performance of the box this much? I compiled the kernel with grsecurty mode 'high' (no customizations).

it's definitely not normal, i've got almost the same CPU and never had this issue. a few tests that would help finding out what goes on there:

1. try the plain PaX patch itself with the same PaX related options
2. try an older version of grsecurity (1.9.9 series)
3. keep disabling features in your current grsecurity config until the problem goes away (you can try some kind of 'binary search' to make it faster)

also, what gcc version and options did you use to compile the kernel? the recommendation (that is known to work) is either 2.95.3 or 3.2.2+ and no extra optimizations (e.g., -O3) beyond what the vanilla kernel makefiles do.