Re: [patch] let CONFIG_SECCOMP default to n

[Ingo Molnar <mingo@elte.hu>]

* Andi Kleen <ak@suse.de> wrote:

> If the TSC disabling code is taken out the runtime overhead of seccomp 
> is also very small because it's only tested in slow paths.

correct. But when i suggested to do precisely that i got a rant from 
Andrea of how super duper important it was to disable the TSC for 
seccomp ... (which argument is almost total hogwash)

so i'm going with the simpler path of making seccomp default-off. (which 
solves the problem as far as i'm concerned - i.e. no default overhead in 
the scheduler.)

but Andrea's creative arguments wrt. his decision to not pledge the 
seccomp related patent to GPL users makes me worry about whether this 
technology is untainted. We _dont_ want to make Linux reliant on 
possibly hostile patents - especially not for core default-enabled 
functionality. Basically Andrea wants us to help his project but he is 
in essence rejecting to do the same for us (for one of the most obvious 
applications of trusted bytecode: over-the-internet clustering via 
seccomp) - i find that approach fundamentally unfair. And he has not 
given a satisfactory answer either - IMO his 'GPL is not good because of 
the corporate firewall licensing backhole' argument is ridiculous [if he 
doesnt like the GPL he should write his own OS i guess, and not try to 
use a GPL-ed kernel as a vehicle for his technology]. (And he has 
injected his code into code that i authored too, which makes it doubly 
offensive to me.)

the fundamental problem is what i sense to be arrogant behavior of 
Andrea all across. I reported a performance problem months ago with two 
simple patches (the first one fixing seccomp, the second one disabling 
it by default) to get rid of the problem, and what i got was insults 
from Andrea and hours spent on writing pointless emails. Andrea is 
forcing me to invest time into this stupidity and that just increases my 
sense of being abused. I also start being of the opinion that no matter 
how good of a coder Andrea is, i dont want to deal with his code _at 
all_ if such _basic_ issues like performance regressions are so hard to 
communicate. At a minimum Andrea should apologize for all that abuse 
that i got just because i happened to cross his tracks with his 
holy-grail patent-pending technology.

another problem is the double standard Andrea's code is enjoying. 
Despite good resons to apply the patch, it has not been applied yet, 
with no explanation. Again, i request the patch below to be applied to 
the upstream kernel. If Andrea fixes the performance problem and fixes 
the patent taining issue we can turn the feature back on. Is Andrea's 
code above the rules of maintainance?

really, how much more stupid can the situation get before we get a 
resolution?

And i just wasted another 15 minutes on this ...

	Ingo

---------------->
From: Ingo Molnar <mingo@elte.hu>
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 <mingo@elte.hu>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

----

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/