From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: [2.6 patch] let CONFIG_SECCOMP default to n
Date: Wed, 19 Apr 2006 00:07:26 +0200 [thread overview]
Message-ID: <20060418220726.GT11582@stusta.de> (raw)
From: Ingo Molnar <mingo@elte.hu>
I was profiling the scheduler on x86 and noticed some overhead related
to SECCOMP, and indeed, SECCOMP runs disable_tsc() at _every_
context-switch:
if (unlikely(prev->io_bitmap_ptr || next->io_bitmap_ptr))
handle_io_bitmap(next, tss);
disable_tsc(prev_p, next_p);
return prev_p;
these are a couple of instructions in the hottest scheduler codepath!
x86_64 already removed disable_tsc() from switch_to(), but i think the
right solution is to turn SECCOMP off by default.
besides the runtime overhead, there are a couple of other reasons as
well why this should be done:
- CONFIG_SECCOMP=y adds 836 bytes of bloat to the kernel:
text data bss dec hex filename
4185360 867112 391012 5443484 530f9c vmlinux-noseccomp
4185992 867316 391012 5444320 5312e0 vmlinux-seccomp
- virtually nobody seems to be using it (but cpushare.com, which seems
pretty inactive)
- users/distributions can still turn it on if they want it
- http://www.cpushare.com/legal seems to suggest that it is pursuing a
software patent to utilize the seccomp concept in a distributed
environment, and seems to give a promise that 'end users' will not be
affected by that patent. How about non-end-users [i.e. server-side]?
Has the Linux kernel become a vehicle for a propriety server-side
feature, with every Linux user paying the price of it?
so the patch below just does the minimal common-sense change: turn it
off by default.
Adrian Bunk:
I've removed the superfluous "default n"'s the original patch introduced.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
----
This patch was already sent on:
- 11 Apr 2006
- 10 Mar 2006
- 29 Jan 2006
- 21 Jan 2006
This patch was sent by Ingo Molnar on:
- 9 Jan 2006
Index: linux/arch/i386/Kconfig
===================================================================
--- linux.orig/arch/i386/Kconfig
+++ linux/arch/i386/Kconfig
@@ -637,7 +637,6 @@ config REGPARM
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
- default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
Index: linux/arch/mips/Kconfig
===================================================================
--- linux.orig/arch/mips/Kconfig
+++ linux/arch/mips/Kconfig
@@ -1787,7 +1787,6 @@ config BINFMT_ELF32
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS && BROKEN
- default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
Index: linux/arch/powerpc/Kconfig
===================================================================
--- linux.orig/arch/powerpc/Kconfig
+++ linux/arch/powerpc/Kconfig
@@ -666,7 +666,6 @@ endif
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
- default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
Index: linux/arch/ppc/Kconfig
===================================================================
--- linux.orig/arch/ppc/Kconfig
+++ linux/arch/ppc/Kconfig
@@ -1127,7 +1127,6 @@ endif
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
- default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
Index: linux/arch/sparc64/Kconfig
===================================================================
--- linux.orig/arch/sparc64/Kconfig
+++ linux/arch/sparc64/Kconfig
@@ -64,7 +64,6 @@ endchoice
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
- default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
Index: linux/arch/x86_64/Kconfig
===================================================================
--- linux.orig/arch/x86_64/Kconfig
+++ linux/arch/x86_64/Kconfig
@@ -466,7 +466,6 @@ config PHYSICAL_START
config SECCOMP
bool "Enable seccomp to safely compute untrusted bytecode"
depends on PROC_FS
- default y
help
This kernel feature is useful for number crunching applications
that may need to compute untrusted bytecode during their
next reply other threads:[~2006-04-18 22:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-18 22:07 Adrian Bunk [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-04-27 20:33 [2.6 patch] let CONFIG_SECCOMP default to n Adrian Bunk
2006-06-26 16:26 Adrian Bunk
2006-06-29 19:21 Adrian Bunk
2006-06-30 0:44 ` Lee Revell
2006-06-30 1:07 ` Andrew Morton
2006-06-30 1:40 ` Adrian Bunk
2006-06-30 4:52 ` Andrea Arcangeli
2006-06-30 9:47 ` Ingo Molnar
2006-06-30 14:58 ` andrea
2006-06-30 12:39 ` Alan Cox
2006-06-30 2:35 ` Randy.Dunlap
2006-06-30 15:03 ` Lee Revell
2006-07-08 9:23 ` Andrea Arcangeli
2006-07-11 1:59 ` Andrew James Wade
2006-07-11 4:16 ` andrea
2006-07-11 20:19 ` Andrew James Wade
2006-07-12 21:05 ` andrea
2006-07-12 22:02 ` Alan Cox
2006-07-12 23:44 ` andrea
2006-07-13 21:29 ` Pavel Machek
2006-07-13 23:11 ` andrea
2006-07-13 23:20 ` Pavel Machek
2006-07-14 0:34 ` andrea
2006-07-15 2:55 ` Valdis.Kletnieks
2006-07-16 0:51 ` andrea
2006-07-16 1:54 ` Pavel Machek
2006-07-16 15:36 ` andrea
2006-07-13 2:56 ` Andrew James Wade
2006-07-12 21:13 ` Ingo Molnar
2006-07-13 1:16 ` andrea
2006-07-13 1:37 ` Andrew James Wade
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060418220726.GT11582@stusta.de \
--to=bunk@stusta.de \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.