Red Hat Bugzilla – Bug 295841
Stop disabling seccomp in kernel config
Last modified: 2007-11-30 17:12:16 EST
Description of problem:
Fedora is currently shipping kernels with seccomp disabled. This is an unneeded
divergence from the stock kernel.
Compiling custom kernels in order to support seccomp is a burden, and the need
to run custom kernels is forcing me to keep cpushare off production systems.
This is more relevant now than it was in the past because the cpushare trading
infrastructure is working now.
Steps to Reproduce:
1. Install fedora
2. Observe seccomp is disabled
3. Install custom kernel with it on
4. Waste life away tracking updates
Seccomp is disabled.
Seccomp is enabled.
As a further reminder, I want to add that despite the clearly biased
misinformation in the wikipedia article about seccomp, seccomp has _never_ had
any chance to slowdown performance on x86-64, ppc and ppc64 (3 archs where
CPUShare runs). With latest mainline seccomp is totally zero cost even on i386
(the 4th arch supported by CPUShare) despite i386 disables the tsc for seccomp
tasks (a feature still missing on x86-64 and not possible on ppc/ppc64).
So I hope they can start by enabling seccomp on x86-64/ppc/ppc64 in their
current kernels for their future updates, and with 2.6.23 they should enable it
even on i386.
I will attach the patches they can apply if they want, to enable seccomp
everywhere even in kernels older than 2.6.23.
Here the two patches to apply on top of any reasonably recent 2.6 kernel to
eliminate all i386 overhead in disabling the tsc with seccomp enabled. The
other patch updates the API to the latest to further reduce the memory
footprint. Both patches have to be applied incrementally because the disable
tsc feature is only safe if it's the current task that enables seccomp on
itself (the proc api had to be obsoleted not just to reduce the .text byte
overhead of a few bytes).
Hope this helps!
Secure Computing will be enabled in Fedora 8, it is now enabled in Rawhide where
we can get some testing.