grsecurity forums

Presently I run 2.4.31-grsec and I am planning on upgrading to a new kernel (I compiled a custom kernel myself with no PAX enabled, mostly just the other sysctl features enabled -- what kind of protection does this offer against exploit attacks like simple overflows?)

Anyhow I have noticed a performance hit when running perl with DBI, it seems there is about an additional 50ms of realtime lag when loading the DBI module with no other functionality in it. At first I thought this was because perl or DBI was not optimized but I ran out of ideas on that and have the assumption it is possible grsecurity can be causing it.

If there are any tweaks to increase filesystem, or memory performance please let me know.

10:03:12 up 247 days, 3:45, 13 users, load average: 0.09, 0.05, 0.00
239 processes: 233 sleeping, 1 running, 0 zombie, 5 stopped
CPU states: 0.3% user 5.0% system 0.0% nice 0.0% iowait 94.5% idle
Mem: 507740k av, 443888k used, 63852k free, 0k shrd, 43320k buff
189880k active, 178652k inactive
Swap: 1052248k av, 160332k used, 891916k free 313200k cached

2.4GHZ Celeron
Linux box0 2.4.31-grsec #1 Thu Sep 22 02:41:44 CDT 2005 i686 i686 i386 GNU/Linux
[root@box0 usr]# time perl -MDBI -e ''

real 0m0.102s
user 0m0.100s
sys 0m0.000s
[root@box0 usr]# time perl -MDBI -e ''

real 0m0.101s
user 0m0.090s
sys 0m0.010s
[root@box0 usr]# time perl -MDBI -e ''

real 0m0.097s
user 0m0.090s
sys 0m0.010s

[root@box0 usr]# strace -cff perl -MDBI -e ''
execve("/usr/bin/perl", ["perl", "-MDBI", "-e", ""], [/* 21 vars */]) = 0
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
46.38 0.002498 4 593 brk
13.76 0.000741 14 54 read
11.60 0.000625 12 51 25 open
9.25 0.000498 14 36 28 stat64
8.17 0.000440 40 11 fstat64
2.95 0.000159 7 22 old_mmap
2.10 0.000113 4 26 close
2.04 0.000110 3 33 3 _llseek
1.15 0.000062 4 17 14 ioctl
0.91 0.000049 49 1 readlink
0.56 0.000030 6 5 mmap2
0.52 0.000028 14 2 munmap
0.15 0.000008 4 2 rt_sigaction
0.09 0.000005 5 1 uname
0.07 0.000004 4 1 fcntl64
0.06 0.000003 3 1 time
0.06 0.000003 3 1 getuid32
0.04 0.000002 2 1 getpid
0.04 0.000002 2 1 getgid32
0.04 0.000002 2 1 geteuid32
0.04 0.000002 2 1 getegid32
0.04 0.000002 2 1 1 set_tid_address
------ ----------- ----------- --------- --------- ----------------
100.00 0.005386 862 71 total

Other time tests

2.6GHz Intel
Linux box1 2.6.14.3-grsec #1 PREEMPT Mon Dec 26 15:50:19 CST 2005 i686 i686 i386 GNU/Linux


[root@box1 root]# time perl -MDBI -e ''

real 0m0.059s
user 0m0.056s
sys 0m0.004s
[root@box1 root]# time perl -MDBI -e ''

real 0m0.063s
user 0m0.048s
sys 0m0.012s
[root@box1 root]# time perl -MDBI -e ''

real 0m0.056s
user 0m0.052s
sys 0m0.004s

2.4GHz Intel
Linux box2 2.4.31-grsec #1 Tue Jun 21 08:59:58 PDT 2005 i686 i686 i386 GNU/Linux
[root@box2 root]# time perl -MDBI -e ''

real 0m0.057s
user 0m0.040s
sys 0m0.010s
[root@box2 root]# time perl -MDBI -e ''

real 0m0.058s
user 0m0.050s
sys 0m0.010s
[root@box2 root]# time perl -MDBI -e ''

real 0m0.057s
user 0m0.050s
sys 0m0.000s

pelham22 wrote:Presently I run 2.4.31-grsec and I am planning on upgrading to a new kernel (I compiled a custom kernel myself with no PAX enabled, mostly just the other sysctl features enabled -- what kind of protection does this offer against exploit attacks like simple overflows?)

nothing.

Anyhow I have noticed a performance hit when running perl with DBI, it seems there is about an additional 50ms of realtime lag when loading the DBI module with no other functionality in it. At first I thought this was because perl or DBI was not optimized but I ran out of ideas on that and have the assumption it is possible grsecurity can be causing it.

to me it seems that you're comparing apples to oranges, the real test would be to run your test under a vanilla kernel on the Celeron box then we can compare numbers. considering how little the system time is however i doubt grsec could be causing the overhead (if there's any at all).