Posted Jul 22, 2005 12:27 UTC (Fri) by mingo
In reply to: Performance impact?
Parent article: Kernel Summit 2005: The ExecShield patches
there's no performance impact from the double-free checks.
you are right about exec-shield being cheap on newest hardware - but it's more than reasonable even on 'legacy' hardware where we apply the 'dynamic segment limit' trick to approximate NX protection. Maintaining the segment limit has some cost but it's not measurable.
What is measurable is overhead on systems that dont have NX but have fast syscall support: there we have to turn off fast syscalls because the fast syscall hardware does not follow segment limits accurately and securely. Fast syscalls are a new feature in the 2.6 kernel which can cut ~0.5 usecs off the syscall entry+exit cost. On CPUs that have neither fast syscalls nor NX (old hardware), or CPUs that have both (new systems), there's no such cost. Also, the difference between fast syscalls and int80 syscalls is more marked on new hardware - which has NX. So while exec-shield might cause a NX-less P3 to not use fast syscalls, the cost of that is not the same as if the latest P4 didnt have fast syscalls.
so in general, the performance overhead of exec-shield is not an issue. Even if it had considerable overhead (which it doesnt), i'd use it personally, considering the tough (and important) problem it tries to solve: to give a fair degree of transparent non-exec protection on CPUs that dont actually have such support in hardware. (i.e. dont have an "exec/dont-exec" bit in their pagetable format.)
Exec-shield is always on in FC1, FC2, FC3, FC4, RHEL3 and RHEL4.
to post comments)