* [email protected] <[email protected]> wrote:
> On Fri, Jun 30, 2006 at 11:47:53AM +0200, Ingo Molnar wrote:
> > and both are pledged and available to GPL users. [..]
>
> If the GPL offered any protection to my system software I would
> consider it too, but the GPL can't protect software that runs behind
> the corporate firewall. [...]
so you admit and confirm that you explicitly and intentionally do not
pledge your patent to GPL users. That is troubling (and unethical) in my
opinion and strengthens my argument that this feature should be _at a
minimum_ be made default-off, just like hundreds of other kernel
features are.
I'm also wondering what the upstream decision would have been, had you
disclosed this patent licensing intention of yours. (to use the GPL-ed
Linux kernel as a vehicle for your 'invention', while not fully living
up to the basic quid-pro-quo.).
and i'm not really interested in marketing arguments about cpushare and
seccomp in general. What matters to me is that this feature has been in
the kernel for more than a year already, that nobody but you is using it
and that _everyone_ using the default kernel options is paying the price
in the context-switch hotpath. (The fact that in my view one of
seccomp's obvious user-space usages is also patent-tainted without a
fair pledge is 'just' icing on the cake.)
So i'd like to request the patch below to be included in v2.6.18.
Ingo
---------------->
From: Ingo Molnar <[email protected]>
Subject: let CONFIG_SECCOMP default to n
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 <[email protected]>
Signed-off-by: Adrian Bunk <[email protected]>
----
This patch was already sent on:
- 19 Apr 2006
- 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
