* Andi Kleen <[email protected]> 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 <[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/
[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]
