[2.6 patch] let CONFIG_SECCOMP default to n

[2.6 patch] let CONFIG_SECCOMP default to n

[Adrian Bunk]

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

[2.6 patch] let CONFIG_SECCOMP default to n

[Adrian Bunk]

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:
- 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

[2.6 patch] let CONFIG_SECCOMP default to n

[Adrian Bunk]

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:
- 27 Apr 2006
- 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

[2.6 patch] let CONFIG_SECCOMP default to n

[Adrian Bunk]

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:
- 26 Jun 2006
- 27 Apr 2006
- 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

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Lee Revell]

On Thu, 2006-06-29 at 21:21 +0200, Adrian Bunk wrote:
> This patch was already sent on:
> - 26 Jun 2006
> - 27 Apr 2006
> - 19 Apr 2006
> - 11 Apr 2006
> - 10 Mar 2006
> - 29 Jan 2006
> - 21 Jan 2006 

3 days ago?  That seems a bit silly.  Why didn't you just ping Andrew on
it?

Andrew, what's the status of this?  Can we get an ACK or a NACK before
this starts getting reposted every day? ;-)

Lee

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrew Morton]

Lee Revell <rlrevell@joe-job.com> wrote:
>
> On Thu, 2006-06-29 at 21:21 +0200, Adrian Bunk wrote:
> > This patch was already sent on:
> > - 26 Jun 2006
> > - 27 Apr 2006
> > - 19 Apr 2006
> > - 11 Apr 2006
> > - 10 Mar 2006
> > - 29 Jan 2006
> > - 21 Jan 2006 
> 
> 3 days ago?  That seems a bit silly.  Why didn't you just ping Andrew on
> it?
> 
> Andrew, what's the status of this?  Can we get an ACK or a NACK before
> this starts getting reposted every day? ;-)
> 

I am stolidly letting the arch maintainers and the developer of this
feature work out what to do.

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Adrian Bunk]

On Thu, Jun 29, 2006 at 06:07:06PM -0700, Andrew Morton wrote:
> Lee Revell <rlrevell@joe-job.com> wrote:
> >
> > On Thu, 2006-06-29 at 21:21 +0200, Adrian Bunk wrote:
> > > This patch was already sent on:
> > > - 26 Jun 2006
> > > - 27 Apr 2006
> > > - 19 Apr 2006
> > > - 11 Apr 2006
> > > - 10 Mar 2006
> > > - 29 Jan 2006
> > > - 21 Jan 2006 
> > 
> > 3 days ago?  That seems a bit silly.  Why didn't you just ping Andrew on
> > it?
> > 
> > Andrew, what's the status of this?  Can we get an ACK or a NACK before
> > this starts getting reposted every day? ;-)
> 
> I am stolidly letting the arch maintainers and the developer of this
> feature work out what to do.

Andrea is proud of getting a patent for the server part [1], so I doubt 
he would be happy with no longer having the client part defaulting to Y...

It might sound a bit strange that although Alan Cox and Linus Torvalds 
even wrote an open letter to the President of the European Parliament
calling "Software patents are also the utmost threat to the development 
of Linux and other free software products" [2]...

One bonus point for people arguing in favor of software patents - even 
Linux actively supports patented services.

cu
Adrian

[1] http://www.cpushare.com/legal
[2] http://www.effi.org/patentit/patents_torvalds_cox.txt

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Randy.Dunlap]

On Thu, 29 Jun 2006 18:07:06 -0700 Andrew Morton wrote:

> Lee Revell <rlrevell@joe-job.com> wrote:
> >
> > On Thu, 2006-06-29 at 21:21 +0200, Adrian Bunk wrote:
> > > This patch was already sent on:
> > > - 26 Jun 2006
> > > - 27 Apr 2006
> > > - 19 Apr 2006
> > > - 11 Apr 2006
> > > - 10 Mar 2006
> > > - 29 Jan 2006
> > > - 21 Jan 2006 
> > 
> > 3 days ago?  That seems a bit silly.  Why didn't you just ping Andrew on
> > it?
> > 
> > Andrew, what's the status of this?  Can we get an ACK or a NACK before
> > this starts getting reposted every day? ;-)
> > 
> 
> I am stolidly letting the arch maintainers and the developer of this
> feature work out what to do.

Bah, options that are not Required should default to n.
I support Adrian's patch.

---
~Randy

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrea Arcangeli]

Hello,

On Fri, Jun 30, 2006 at 03:40:50AM +0200, Adrian Bunk wrote:
> Andrea is proud [..]

I wish I could be proud of it like you suggest, but for now it remains
to be seen if it will be approved and useful, perhaps one day will pay
off and I could be proud of the hard work, but for now I'm being very
cautious.

> [..] so I doubt 
> he would be happy with no longer having the client part defaulting to
> Y... [..]

Correct but this is a purely technical matter, let's not confuse
technical issues with strict bureaucracy.

> It might sound a bit strange that although Alan Cox and Linus Torvalds 
> even wrote an open letter to the President of the European Parliament
> calling "Software patents are also the utmost threat to the development 
> of Linux and other free software products" [2]...

Alan filed too:

	http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&d=PG01&s1=%22alan+cox%22&OS="alan+cox"&RS="alan+cox"

Ingo who started this focus on disabling seccomp by default filed too:

	http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=molnar&s2=ingo&OS=molnar+AND+ingo&RS=molnar+AND+ingo

FWIW I agree that patents at large are one of the threats to the
development of linux and other free software. But it's not me that
you've to talk with if you want to change the system. I can only agree
with Linus, Alan and you. Like most others here I would be _very_ happy
if all patents would suddently disappear, not just the software patents.

Infact you should inform yourself on the usages of your cpu resources if
you're donating them:

	http://ubuntuforums.org/archive/index.php/t-31418.html"***</t-116861.html

As far as CPUShare is concerned that problem doesn't exist because it's
not a donation, so it's up to you to ask a fair price.

> One bonus point for people arguing in favor of software patents - even 
> Linux actively supports patented services.

Not quite, all open source or proprietary OS out there are free to add
seccomp to their kernels, I will never have any right about the seccomp
idea no matter what.

BTW, I suggested a few weeks ago to the rpm maintainer to use seccomp to
validate the rpm header data because he wasn't convinced that such code
could be trusted. It seems he was looking into it. There are many other
possible usages but nobody ever got intersted to implement them so far.

I think Y is the right setting. If something I can add a secondary
config option for the tsc disable and set that one to N, but the global
CONFIG_SECCOMP should be set to Y beause it generates absolutely zero
overhead, not just pratically but theoretically too.

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

* Andrea Arcangeli <andrea@cpushare.com> wrote:

> Alan filed too:

> Ingo who started this focus on disabling seccomp by default filed too:

and both are pledged and available to GPL users. Is yours?

	Ingo

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Alan Cox]

Ar Gwe, 2006-06-30 am 03:40 +0200, ysgrifennodd Adrian Bunk:
> > I am stolidly letting the arch maintainers and the developer of this
> > feature work out what to do.
> 
> Andrea is proud of getting a patent for the server part [1], so I doubt 
> he would be happy with no longer having the client part defaulting to Y...

If Andrea has clear personal business interests in that decision then
perhaps you could make the case he shouldn't make the decision as to
whether it should be Y or not, or that someone should review it. No big
deal. There are lots of uses for that code. None of them appear
interesting 8)

I don't think its actually important because distributions make their
own decisions about such questions and most of the running kernels are
distribution ones. 

As to patented code for the kernel. That itself is a non-issue providing
the patent owner or someone with permission from them submitted the
code. The law recognizes that you cannot go around making promises
(estoppel) and then trying to sue people for acting on them. The GPL
likewise makes this clear.

> It might sound a bit strange that although Alan Cox and Linus Torvalds 
> even wrote an open letter to the President of the European Parliament
> calling "Software patents are also the utmost threat to the development 
> of Linux and other free software products" [2]...

The Red Hat position on patents is on the web site, along with the
permissions for GPL use. It makes clear the view we have on patents for
software.

Alan

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

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. You know google can change the kernel without
having to release anything back (note that they a few times posted me
patches and fixes, so they at least try to contribute their changes back
to the community, it's in their interest I think, but I'm just saying
they're not _required_ to publish the exact copy of the kernel that runs
on their servers, if I'm wrong then please send me the link where to
download it). So if I would release my software as GPL anybody with a
bigger web farm than I have could install it, throw some million on ads,
and then I could just setup a redirect from my server that points at
theirs because I would have no chance to survive a competitor with
better financing. Make a license that forces them to release the
software behind the firewall like they have to do if they offer it as
download, and I will think about it. And at the moment thinking about it
or trying writing a license like that myself, is just wasted time. I'll
think about these matters only if it will accepted.

And for yours that covers the http optimizations inside the http
accellerator, apache and other open source webservers aren't GPL and if
you only pledged it under the GPL like you suggest above, apache still
is forbidden to use your technique:

	http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=5&f=G&l=50&co1=AND&d=PG01&s1=molnar&s2=ingo&OS=molnar+AND+ingo&RS=molnar+AND+ingo

Same goes for sendmail in the mail one, assuming it has something to do
with the mail (I didn't read it all since it's not my field of
interest).

If I've to keep reading these threads about CONFIG_SECCOMP every few
months then set it to N (even if I disagree with that setting). Like
Alan said, what really matters is what distro will choose in their
config, not the default (and I doubt fedora ships with cifs=Y like the
default where only the required stuff is set to Y, please focus on the
big stuff first ;).

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Lee Revell]

On Thu, 2006-06-29 at 19:35 -0700, Randy.Dunlap wrote:
> On Thu, 29 Jun 2006 18:07:06 -0700 Andrew Morton wrote:
> 
> > Lee Revell <rlrevell@joe-job.com> wrote:
> > >
> > > On Thu, 2006-06-29 at 21:21 +0200, Adrian Bunk wrote:
> > > > This patch was already sent on:
> > > > - 26 Jun 2006
> > > > - 27 Apr 2006
> > > > - 19 Apr 2006
> > > > - 11 Apr 2006
> > > > - 10 Mar 2006
> > > > - 29 Jan 2006
> > > > - 21 Jan 2006 
> > > 
> > > 3 days ago?  That seems a bit silly.  Why didn't you just ping Andrew on
> > > it?
> > > 
> > > Andrew, what's the status of this?  Can we get an ACK or a NACK before
> > > this starts getting reposted every day? ;-)
> > > 
> > 
> > I am stolidly letting the arch maintainers and the developer of this
> > feature work out what to do.
> 
> Bah, options that are not Required should default to n.
> I support Adrian's patch.

Agreed:

- Most people don't use it
- There's a performance hit

Clearly should default to N.

Lee

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrea Arcangeli]

On Fri, Jun 30, 2006 at 11:03:00AM -0400, Lee Revell wrote:
> On Thu, 2006-06-29 at 19:35 -0700, Randy.Dunlap wrote:
> > On Thu, 29 Jun 2006 18:07:06 -0700 Andrew Morton wrote:
> > 
> > > Lee Revell <rlrevell@joe-job.com> wrote:
> > > >
> > > > On Thu, 2006-06-29 at 21:21 +0200, Adrian Bunk wrote:
> > > > > This patch was already sent on:
> > > > > - 26 Jun 2006
> > > > > - 27 Apr 2006
> > > > > - 19 Apr 2006
> > > > > - 11 Apr 2006
> > > > > - 10 Mar 2006
> > > > > - 29 Jan 2006
> > > > > - 21 Jan 2006 
> > > > 
> > > > 3 days ago?  That seems a bit silly.  Why didn't you just ping Andrew on
> > > > it?
> > > > 
> > > > Andrew, what's the status of this?  Can we get an ACK or a NACK before
> > > > this starts getting reposted every day? ;-)
> > > > 
> > > 
> > > I am stolidly letting the arch maintainers and the developer of this
> > > feature work out what to do.
> > 
> > Bah, options that are not Required should default to n.
> > I support Adrian's patch.
> 
> Agreed:
> 
> - Most people don't use it
> - There's a performance hit

On x86-64 SECCOMP generates absoutely zero performance hit.

The original seccomp patch for x86 also generated absolutely zero
performance hit, both pratically and theoretically too. _zero_ CPU
cycles of difference, zero cachelines.

What generates a minuscle overhead is a feature I added later on top of
SECCOMP, that disables TSC for SECCOMP tasks. I thought such minuscle
overhead wouldn't be measurable compared to all other heavyweight work
we do in the scheduler (note that unless you sell cpu through CPUShare
actively this overhead consists in two cacheline touches per context
switch), but anyway I agree it's good idea to make it optional so
there will be absolutely no reason left to leave seccomp disabled by
default anymore.

Andi thinks the feature is absolutely unnecessary, he's certainly right,
and it has been there only for paranoid reasons.

	http://www.cpushare.com/blog/CPUShare/article/26/

> Clearly should default to N.

I think the best is to add a CONFIG_SECCOMP_DISABLE_TSC obviously
defaulted to N, so seccomp returns absolutely zerocost and everybody
will be happy (me included for sure, since I agree with Andi, except I
can't be sure of it and that's the only reason why I developed the tsc
disable feature).

I strongly agree with leaving CONFIG_SECCOMP_DISABLE_TSC set to N by
default.

-------------

Make the TSC disable purely paranoid feature optional, so by default seccomp
returns absolutely zerocost.

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>

diff -r 67137165b47d arch/i386/Kconfig
--- a/arch/i386/Kconfig	Thu Jul 06 19:45:01 2006 +0200
+++ b/arch/i386/Kconfig	Sat Jul 08 11:06:49 2006 +0200
@@ -734,6 +734,18 @@ config SECCOMP
 	  defined by each seccomp mode.
 
 	  If unsure, say Y. Only embedded should say N here.
+
+config SECCOMP_DISABLE_TSC
+	bool "Disable the TSC for seccomp tasks"
+	depends on SECCOMP
+	default n
+	help
+	  This feature mathematically prevents covert channels
+	  for tasks running under SECCOMP. This can generate
+	  a minuscule overhead in the scheduler.
+
+	  If you care most about performance say N. Say Y only if you're
+	  paranoid about covert channels.
 
 source kernel/Kconfig.hz
 
diff -r 67137165b47d arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c	Thu Jul 06 19:45:01 2006 +0200
+++ b/arch/i386/kernel/process.c	Sat Jul 08 11:05:35 2006 +0200
@@ -572,6 +572,7 @@ static inline void disable_tsc(struct ta
 static inline void disable_tsc(struct task_struct *prev_p,
 			       struct task_struct *next_p)
 {
+#ifdef CONFIG_SECCOMP_DISABLE_TSC
 	struct thread_info *prev, *next;
 
 	/*
@@ -590,6 +591,7 @@ static inline void disable_tsc(struct ta
 			   has_secure_computing(next))
 			write_cr4(read_cr4() | X86_CR4_TSD);
 	}
+#endif
 }
 
 /*
diff -r 67137165b47d arch/x86_64/Kconfig
--- a/arch/x86_64/Kconfig	Thu Jul 06 19:45:01 2006 +0200
+++ b/arch/x86_64/Kconfig	Sat Jul 08 11:06:40 2006 +0200
@@ -522,6 +522,18 @@ config SECCOMP
 
 	  If unsure, say Y. Only embedded should say N here.
 
+config SECCOMP_DISABLE_TSC
+	bool "Disable the TSC for seccomp tasks"
+	depends on SECCOMP
+	default n
+	help
+	  This feature mathematically prevents covert channels
+	  for tasks running under SECCOMP. This can generate
+	  a minuscule overhead in the scheduler.
+
+	  If you care most about performance say N. Say Y only if you're
+	  paranoid about covert channels.
+
 source kernel/Kconfig.hz
 
 config REORDER
diff -r 67137165b47d arch/x86_64/kernel/process.c
--- a/arch/x86_64/kernel/process.c	Thu Jul 06 19:45:01 2006 +0200
+++ b/arch/x86_64/kernel/process.c	Sat Jul 08 11:05:26 2006 +0200
@@ -494,6 +494,35 @@ out:
 }
 
 /*
+ * This function selects if the context switch from prev to next
+ * has to tweak the TSC disable bit in the cr4.
+ */
+static inline void disable_tsc(struct task_struct *prev_p,
+			       struct task_struct *next_p)
+{
+#ifdef CONFIG_SECCOMP_DISABLE_TSC
+	struct thread_info *prev, *next;
+
+	/*
+	 * gcc should eliminate the ->thread_info dereference if
+	 * has_secure_computing returns 0 at compile time (SECCOMP=n).
+	 */
+	prev = prev_p->thread_info;
+	next = next_p->thread_info;
+
+	if (has_secure_computing(prev) || has_secure_computing(next)) {
+		/* slow path here */
+		if (has_secure_computing(prev) &&
+		    !has_secure_computing(next)) {
+			write_cr4(read_cr4() & ~X86_CR4_TSD);
+		} else if (!has_secure_computing(prev) &&
+			   has_secure_computing(next))
+			write_cr4((read_cr4() | X86_CR4_TSD) & ~X86_CR4_PCE);
+	}
+#endif
+}
+
+/*
  * This special macro can be used to load a debugging register
  */
 #define loaddebug(thread,r) set_debugreg(thread->debugreg ## r, r)
@@ -617,6 +646,8 @@ __switch_to(struct task_struct *prev_p, 
 			memset(tss->io_bitmap, 0xff, prev->io_bitmap_max);
 		}
 	}
+
+	disable_tsc(prev_p, next_p);
 
 	return prev_p;
 }

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrew James Wade]

On Saturday 08 July 2006 05:23, Andrea Arcangeli wrote:
..
> (note that unless you sell cpu through CPUShare
> actively this overhead consists in two cacheline touches per context
> switch),

It's probably not worth the complication, but I suppose that could be
reduced to one cacheline by lazily enabling the TSC access.

...
> +	  This feature mathematically prevents covert channels
> +	  for tasks running under SECCOMP.

I disagree with this wording. First, for most users the worry isn't so
much covert channels, as it is side channels. In other words, the
worry is not so much that data is sent to the SECCOMP process
secretly, as that the data could be sensitive. Second, the feature
closes one only one type of side-channel; others may still exist. It's
quite possible for cpu bugs or undefined behaviour to reveal internal
cpu state (possibly affected by another process) without otherwise
being security risks. (In my uninformed opinion). I wouldn't worry
about such side channels myself, but they do likely exist.

Suggested wording as a patch against 2.6.18-rc1-mm1:
------

Change help text for SECCOMP_DISABLE_TSC to warn about
side channels (the larger concern) instead of covert channels.

signed-off-by: Andrew Wade <andrew.j.wade@gmail.com>
---

diff -rupN a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig	2006-07-10 21:00:37.000000000 -0400
+++ b/arch/i386/Kconfig	2006-07-10 21:37:12.000000000 -0400
@@ -748,12 +748,12 @@ config SECCOMP_DISABLE_TSC
 	depends on SECCOMP
 	default n
 	help
-	  This feature mathematically prevents covert channels
-	  for tasks running under SECCOMP. This can generate
-	  a minuscule overhead in the scheduler.
+	  This feature closes potential side channels for tasks
+	  running under SECCOMP. Enabling this can generate a
+	  miniscule overhead in the scheduler.
 
 	  If you care most about performance say N. Say Y only if you're
-	  paranoid about covert channels.
+	  paranoid about security.
 
 config VGA_NOPROBE
        bool "Don't probe VGA at boot" if EMBEDDED
diff -rupN a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
--- a/arch/x86_64/Kconfig	2006-07-10 21:00:40.000000000 -0400
+++ b/arch/x86_64/Kconfig	2006-07-10 21:44:59.000000000 -0400
@@ -537,12 +537,12 @@ config SECCOMP_DISABLE_TSC
 	depends on SECCOMP
 	default n
 	help
-	  This feature mathematically prevents covert channels
-	  for tasks running under SECCOMP. This can generate
-	  a minuscule overhead in the scheduler.
+	  This feature closes potential side channels for tasks
+	  running under SECCOMP. Enabling this can generate a
+	  miniscule overhead in the scheduler.
 
 	  If you care most about performance say N. Say Y only if you're
-	  paranoid about covert channels.
+	  paranoid about security.
 
 source kernel/Kconfig.hz
 

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

Hello,

On Mon, Jul 10, 2006 at 09:59:09PM -0400, Andrew James Wade wrote:
> It's probably not worth the complication, but I suppose that could be
> reduced to one cacheline by lazily enabling the TSC access.

Yep, OTOH lazily enabling means generating exception faults and
enter/exit kernels that takes order of magnitude more time and stall the
pipeline unlike the two cacheline touches. So that may be ok on x86
(well modulo a few apps that I know do a flood of rdtsc and infact
you've to disable them on numa), but x86-64 may be using it more
frequently through vgettimeofday in some UP configuration, making the
optimization dubious.

I already tried to reduce the number of cacheline touches to zero and
without risking exception faults by relocating the seccomp_t in the
task_t, but I removed that part from the last patch just to make it 100%
strightforward.

> I disagree with this wording. First, for most users the worry isn't so
> much covert channels, as it is side channels. In other words, the
> worry is not so much that data is sent to the SECCOMP process
> secretly, as that the data could be sensitive. Second, the feature

Well, this comes as a news because with covert channel I always meant
your "side channel" and only in timing context. Perhaps it was just me
misunderstanding ;).  But we obviously agree, I meant your side channel
if you're the one right about the wording.

> closes one only one type of side-channel; others may still exist. It's
> quite possible for cpu bugs or undefined behaviour to reveal internal

Well math guarantees and unpredictable hardware issues don't go well
together. If there are cpu bugs the least thing anybody (not just the
seccomp users) can care about is the covert channel.

> cpu state (possibly affected by another process) without otherwise
> being security risks. (In my uninformed opinion). I wouldn't worry

Any bug that affects seccomp security is always a security bug for
everyone else too (in terms of multiuser security of course).

I'll also give you the perfect example of a side channel not related to
timing attacks if that's what you meant (I thought covert channels were
only about timing attacks): see the mmx example that I can quote here
taken out of a webpage of my site (pathname /technical):

	The most severe attack possible I'm aware of is the mmx
	incorrect initialization caused by the MMX capable cpus not being
	backwards compatible with previous Pentium cpus. No computer could have
	been permanently compromised by such an attack and a simple kernel
	upgrade would have fixed the problem.

That was affecting all multiuser systems, and it wasn't really a cpu
bug (though it's hard to call it a "feature" ;), it was just the newer
cpus not being "security" backwards compatible.

f00f was a real cpu bug instead and it lead to a DoS.

The opposite isn't true, a security bug for everyone, is pratically
never a bug for seccomp. Historically backtesting seccomp, the only
exceptions I'm aware of have been the above mmx data leak,
the f00f and some fdiv bug in the kernel (not a cpu bug) also were
dosable. But we never even got close to exploitability as far as I can
remember, and that's after all the most important thing.

Running linux seccomp under the vista virtualization will be even more
secure than running it on top of the bare hardware, because if there are
_kernel_ bugs that makes seccomp expoitable, things will be still secure
and no reinstall will be necessary since the iso will be mounted
readonly and there will be no access to any filesystem or harddisk (it
all runs in ramfs).

> about such side channels myself, but they do likely exist.

Nothing can be guaranteed perfect, and if something I'm more worried
about kernel bugs than about cpu bugs. It's all a matter of probability,
if it's more likely that you're being hit by an asteroid, then that your
CPU has a bug that allows an attacker to execute code outside seccomp, I
think you should be fine ;). Though it's probably more likely that the
CPU has a bug than we are hit by an asteroid (or at least I hope so).

>From another POV if any seccomp related usage really can save energy, I
suppose that's less risky than producing the saved energy with fission
(we could argue about oil).

> Suggested wording as a patch against 2.6.18-rc1-mm1:
> ------
> 
> Change help text for SECCOMP_DISABLE_TSC to warn about
> side channels (the larger concern) instead of covert channels.
> 
> signed-off-by: Andrew Wade <andrew.j.wade@gmail.com>
Acked-by: Andrea Arcangeli <andrea@cpushare.com>

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrew James Wade]

Hello,

On Tuesday 11 July 2006 00:16, andrea@cpushare.com wrote:
> Hello,
> 
> On Mon, Jul 10, 2006 at 09:59:09PM -0400, Andrew James Wade wrote:
> > It's probably not worth the complication, but I suppose that could be
> > reduced to one cacheline by lazily enabling the TSC access.
> 
> Yep, OTOH lazily enabling means generating exception faults and
> enter/exit kernels that takes order of magnitude more time and stall the
> pipeline unlike the two cacheline touches.

But only if SECCOMP code runs, otherwise it's never needed. OTOH, if it
can't reduce the number of cacheline touches over a tuned seccomp common
case, there's no benefit either.

> > I disagree with this wording. First, for most users the worry isn't so
> > much covert channels, as it is side channels. In other words, the
> > worry is not so much that data is sent to the SECCOMP process
> > secretly, as that the data could be sensitive. Second, the feature
> 
> Well, this comes as a news because with covert channel I always meant
> your "side channel" and only in timing context. Perhaps it was just me
> misunderstanding ;).  But we obviously agree, I meant your side channel
> if you're the one right about the wording.

I'm not an expert, but I believe I'm using the terminology correctly.

> > closes one only one type of side-channel; others may still exist. It's
> > quite possible for cpu bugs or undefined behaviour to reveal internal
> 
> Well math guarantees and unpredictable hardware issues don't go well
> together.

Yes. By necessity any proofs about software must make assumptions that
aren't quite valid. Such proofs can still be useful of course. I think
we're in agreement.

> If there are cpu bugs the least thing anybody (not just the 
> seccomp users) can care about is the covert channel.
> 
> > cpu state (possibly affected by another process) without otherwise
> > being security risks. (In my uninformed opinion). I wouldn't worry
> 
> Any bug that affects seccomp security is always a security bug for
> everyone else too (in terms of multiuser security of course).

Yes. But it is possible for the only exploitable side-effect of a bug
to be the opening of a side-channel. The incorrect fp initialization
being almost a case in point; all programs outside the jail would
likely ignore initial values in mmx registers, but they would still be
vulnerable to their floating point state being read. That's probably
not useful information to an attacker. Many other side channels are
likely similar, in that the information revealed is not actually
useful to the attacker. f00f also has very limited security
implications, as I understand it.

The various software and hardware caches will open a plethora of
timing side channels, almost all useless to an attacker in that the
revealed information is uninteresting/useless. At least I would hope
so. The downside of security is that it is hard to be sure.

> The opposite isn't true, a security bug for everyone, is pratically
> never a bug for seccomp.

Ah, fail safe. Nice property to have. From my observation, userspace
does appear to have something of that property with regards to cpu
bugs as well. What I recall from the errata sheets is that many of the
bugs could only be triggered from privileged code.

...

> It's all a matter of probability,
> if it's more likely that you're being hit by an asteroid, then that your 
> CPU has a bug that allows an attacker to execute code outside seccomp, I
> think you should be fine ;).

And that's where fail-safe and simple design comes in. In this
application an oops is better than a jail-break by orders of
magnitude. But then that's why you wrote seccomp instead of using
ptrace in the first place.

Andrew Wade

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

Hello,

On Tue, Jul 11, 2006 at 04:19:35PM -0400, Andrew James Wade wrote:
> But only if SECCOMP code runs, otherwise it's never needed. OTOH, if it
> can't reduce the number of cacheline touches over a tuned seccomp common
> case, there's no benefit either.

Yep.

> I'm not an expert, but I believe I'm using the terminology correctly.

Nobody else answered so you must be right then ;).

> Yes. By necessity any proofs about software must make assumptions that
> aren't quite valid. Such proofs can still be useful of course. I think
> we're in agreement.

We are.

> useful to the attacker. f00f also has very limited security
> implications, as I understand it.

f00f has very limited implications and it would be immediately stopped
from creating further damage (I could even autodetect it with some
clever heuristic). In fact on architectures with the NX bit the stack
can be marked not executable too, so then I could make self-modifying
code impossible, and in turn I would be able to filter out bytecode
reliably on the server. So even if a CPU has a bug not possible to
workaround in the kernel (like with the idt marked readonly) I could
prevent such a bug to be exploited thanks to the NX bit. The only
self-modifying code allowed currently is on the user stack and nothing
else. I didn't bother to enable the NX bit yet because most i686
misses it and there are not (yet) security related bugs that requires
bytecode filtering to be workarounded (and if they will appear, it
means such a cpu will be insecure for multiuser systems on linux
without any hope of software workarounds, only my special seccomp
usage could prevent such a CPU bug to trigger by filtering the
bytecode).

> The various software and hardware caches will open a plethora of
> timing side channels, almost all useless to an attacker in that the
> revealed information is uninteresting/useless. At least I would hope
> so. The downside of security is that it is hard to be sure.

The whole point of the tsc disable was exactly to be sure there are no
timing side channels. If they can't access an accurate source of time
information the very bytecode that attempts to measure the time will
simply get killed instantly.

Measuring time through the network currently is impractical, the rtt is
too huge for that (though perhaps 10 years from now we'll have to
rethink about this).

> Ah, fail safe. Nice property to have. From my observation, userspace
> does appear to have something of that property with regards to cpu
> bugs as well. What I recall from the errata sheets is that many of the
> bugs could only be triggered from privileged code.

Right.

> And that's where fail-safe and simple design comes in. In this
> application an oops is better than a jail-break by orders of

An oops or more generically a system crash.

> magnitude. But then that's why you wrote seccomp instead of using
> ptrace in the first place.

Exactly ;).

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

* Andrew James Wade <andrew.j.wade@gmail.com> wrote:

> And that's where fail-safe and simple design comes in. In this 
> application an oops is better than a jail-break by orders of 
> magnitude. But then that's why you wrote seccomp instead of using 
> ptrace in the first place.

actually, the client side of ptrace isnt all that more complex. I guess 
one of the main problems with using ptrace was that it has no catchy 
name that Andrea could claim for his project and that it couldnt be 
patented ;-)

Andrea could have isolated the 'client side' functionality of ptrace 
(which is often confused with the 'server side' of ptrace - where the 
overwhelming majority of ptrace security holes were located) and he 
could have made it simple to review, to get a comparable 'feeling' of 
security. [User Mode Linux uses the client-side ptrace model to execute 
untrusted code.]

Andrea could also have extended ptrace to solve whatever marginal 
problems he has with ptrace. [in fact such extension of ptrace was 
posted recently, see Roland McGrath's utrace framework!]

But he chose not to do so - and that has nothing to do with being unable 
to improve ptrace - it evidently is improvable. So i see SECCOMP being 
the result of the NIH syndrome.

	Ingo

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Alan Cox]

Ar Mer, 2006-07-12 am 23:05 +0200, ysgrifennodd andrea@cpushare.com:
> Measuring time through the network currently is impractical, the rtt is
> too huge for that (though perhaps 10 years from now we'll have to
> rethink about this).

Actually measuring time through the network is extremely doable given
enough samples as is communication through delay perturbation. A good
viterbi encoder/decoder will fish a signal out of very high noise. Yes
you pay a lot in data rate at that point but it works.

Anyway at the point you pass the bytecode through a processing filter
you don't need SECCOMP because your filter can remove any syscall
attempts. 

Alan

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

On Wed, Jul 12, 2006 at 11:02:56PM +0100, Alan Cox wrote:
> Actually measuring time through the network is extremely doable given
> enough samples as is communication through delay perturbation. A good
> viterbi encoder/decoder will fish a signal out of very high noise. Yes
> you pay a lot in data rate at that point but it works.

Currently the bandwidth is free, I'll charge for the transaction
associated bandwidth only if I'm forced to (which would happen quickly
if people starts doing the above ;).

The way the current transactions are running as we speak, is not like
in a full peer to peer system. It's half peer to peer, a trusted node
always sits in between buyer and seller. I need this for a multitude
of reasons (I could offload the middle node in a p3p system that is
reliable as long as only 1 of the 3 is malicious but it's certainly
more secure if the node in the middle is fully trusted so I'll try to
avoid that). So if you are right, my trusted node will simply add
/dev/urandom delay as needed before forwarding any packet, to prevent
any meaningful measurement. Any network side channel can be solved in
a few liner patch and very quickly.

Theoretically speaking everything is possible, but pratically speaking
I will defer any further thought about this 10 years in the future
because I think it's impossible to measure any signal with nanosecond
frequency, over a connection with millisecond resolution passing
through a randomization of tcp/ip kernel code, slowdown of the python
interpreter and kernel pipes until it finally reaches the seccomp
bytecode and then same way backwards. (plus virtualization on vista)

I rate the network side channel even less probable than the TSC one
(which is purely theoretical too like Andi can certainly confirm).

> Anyway at the point you pass the bytecode through a processing filter
> you don't need SECCOMP because your filter can remove any syscall
> attempts. 

Even if I wanted to run the filtered (but originally untrusted)
bytecode out of any jail, I need the NX bit to do that, and I don't
have it in a large part of the (currently tiny) userbase. In the
previous email I wasn't accurate saying self modifying code is only
possible on the stack, obviously it's possibly in the heap too, so not
even the non-executable-stack patches could help. SECCOMP is the only
feasible basic mode to cover all systems >=i686 (I don't support i586
and lower because I think it's not worth the bandwidth they would
generate, and if I'm wrong I can add them later, ia64 is also not
supported and that has higher prio if something).

Security is about having tons of things to break before you gain ring
0 privilege. It'd be totally wrong in security terms to remove
zerocost SECCOMP (or trusted-xen) just because you added a further
security measure on top of seccomp (or xen). It's like leaving the
door of your apartment open just because you enabled the security
alarm (you want to do both don't you?).

The more security you have the better, especially when it's zero cost
like seccomp.

Furthermore the filter would need to know about all archs and
bytecodes in the world, arch details and all possible ways to enter
kernel, it would need to be maintained out of sync with the kernel
development and it would be of an huge complexity compared to the few
liner seccomp patch (all high risk stuff compared to SECCOMP).

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

I think this thread is not worth reading but since you tell me that I
am affected by NIH syndrome...

On Wed, Jul 12, 2006 at 11:13:58PM +0200, Ingo Molnar wrote:
> But he chose not to do so - and that has nothing to do with being unable 
> to improve ptrace - it evidently is improvable. So i see SECCOMP being 
> the result of the NIH syndrome.

	http://www.cpushare.com/hypermail/cpushare-discuss/06/01/0086.html

	"so if you walk this thought-experiment a bit, you'll quickly arrive to a 
	virtual machine that is actually pretty useful already, and is fully 
	provable. You should not dismiss this as "I dont trust it because it's 
	at ring 0", unless you can show some fatal flaw in my thinking."

In short a few months ago you told me that instead of using SECCOMP I
should filter and run the resulting filtered (but originally
untrusted) bytecode in ring0 inside the kernel without any memory
protection, because your filter was a lot more than the "int 0x80
checks plus jump offsets checks" (that Alan just mentioned), you
suggested a sort of kernel virtual machine that you just invented that
would verify where the bytecode could touch the ram. So the first bug
in this hugely complicated (and IMHO nearly impossible to implement
filter due the lack of memory protection) gives the attacker ring0
privilege because it all runs inside the kernel...

If it's you, inventing it the huge complicated insecure and probably
impossible to realize virtual machine in the kernel, it's ok. While if
it's me, I should be using ptrace instead of the simpler and much more
secure seccomp. If the above is not NIH syndrome I don't know what
that is.

About your first claim, as far as I'm concerned, if I use seccomp or
ptrace it doesn't change anything at all for me. It only changes for
the *users* because if I use ptrace they'll be less secure.

If not obvious yet the reasons of seccomp are multiple.

1) gdb (all buyers of the CPU resources will need a way to debug their
   own bytecode by running the sell client on their own machine, if
   something goes wrong). If seccomp will be used by others to do
   secure decompression, the fact gdb will keep working will be
   welcome for the same reason.
2) strace (I used it quite a lot of times to debug problems in seccomp
   bytecode myself already, it has been a fundamental debugging tool
   as usual)
3) not being susceptible to the newest ptrace addition of the day (you
   just mentioned a ptrace rework with the utrace framework).
4) I didn't want to require an userland knowledge of kernel details
   like syscall numbers and signal details for all archs (the signal
   part could even go out of sync with the kernel).
5) being simple, so less likely to be buggy. ptrace security is
   extremely complex, just the case where the ptracer tasks gets
   killed and the ptraced tasks must be synchronously sigkilled too is
   a controlled race in itself (that again could break after the
   frequent ptrace reworks you just mentioned and since it's a race
   condition it may go unnoticed for a while).
6) Ptrace is generally not being used for critical security features,
   it's primarly a debugging kludge, and others (including my ex. prof) are
   using it for virtualization similar in UML. But they're not running
   untrusted bytecode inside UML or in their virtualization software.
   No major outbreak would happen if ptrace suddenly breaks after one
   of the frequent reworks that you just mentioned.

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrew James Wade]

On Wednesday 12 July 2006 17:13, Ingo Molnar wrote:
...
> actually, the client side of ptrace isnt all that more complex.

Ah. I'm out of my depth here. 

Andrew Wade

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Andrew James Wade]

On Wednesday 12 July 2006 18:02, Alan Cox wrote:
...
> Actually measuring time through the network is extremely doable given
> enough samples as is communication through delay perturbation. A good
> viterbi encoder/decoder will fish a signal out of very high noise. Yes
> you pay a lot in data rate at that point but it works.

The data rate is important: it can mean a difference between an attack
that is practical and one that is impractical. Although I suspect the
orders of magnitude in the sampling rate of rdtsc versus network
packet times is more important. Another source of timing information
could be two seccomp threads (scheduled to different cores/SMT
threads) comparing their relative progress. What made the L1 cache
miss side-channel so interesting was its very high bandwidth. Relative
progress timing techniques will yield lower side-channel bandwidth on
many interesting configurations.

> Anyway at the point you pass the bytecode through a processing filter
> you don't need SECCOMP because your filter can remove any syscall
> attempts. 

Both int 80 and the rdtsc instructions are only 2 bytes long: they'll
generate too many false positives. It may be practical to filter out
the "f00f" instructions though. 
And filtering isn't fail-safe from a security point-of-view: if you
miss a case you lose. For example, can the f00f bug still be triggered
if there are prefixes between the lock prefix and the cmpxchg8b? I
don't know, but if so you'll need to filter for those cases too.

Filtering may be a good idea, but I wouldn't want to rely on it alone.

Andrew Wade

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Pavel Machek]

Hi!

> > Actually measuring time through the network is extremely doable given
> > enough samples as is communication through delay perturbation. A good
> > viterbi encoder/decoder will fish a signal out of very high noise. Yes
> > you pay a lot in data rate at that point but it works.
> 
> Currently the bandwidth is free, I'll charge for the transaction
> associated bandwidth only if I'm forced to (which would happen quickly
> if people starts doing the above ;).
> 
> The way the current transactions are running as we speak, is not like
> in a full peer to peer system. It's half peer to peer, a trusted node
> always sits in between buyer and seller. I need this for a multitude
> of reasons (I could offload the middle node in a p3p system that is
> reliable as long as only 1 of the 3 is malicious but it's certainly
> more secure if the node in the middle is fully trusted so I'll try to
> avoid that). So if you are right, my trusted node will simply add
> /dev/urandom delay as needed before forwarding any packet, to prevent
> any meaningful measurement. Any network side channel can be solved in
> a few liner patch and very quickly.

Actually random delays are unlike to help (much). You have just added
noise, but you can still decode original signal...

-- 
Thanks for all the (sleeping) penguins.

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

On Thu, Jul 13, 2006 at 09:29:41PM +0000, Pavel Machek wrote:
> Actually random delays are unlike to help (much). You have just added
> noise, but you can still decode original signal...

You're wrong, the random delays added to every packet will definitely
wipe out any signal.

But regardless of what is the best fix for the network attack I quote
Ingo:

   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)

Now if the availability of the nanosecond precision of the TSC is
almost total hogwash, how can the network attack be a real concern?

Either the NOTSC feature is critically important (and I don't think it
is but it's not total hogwash either), or the network attach is an
absolute red-herring.

You can't get it both ways. It can't be the NOTSC isn't needed but the
network attack is a serious concern.

What is currently shocking me is that if you really think the network
attack isn't an absolute red-herring, then it's very weird you're
answering to my email instead of answering to Ingo when he says the
availability of the TSC is almost total hogwash.

And please feel free to demonstrate the network attack, remote seccomp
computations are already possible so if you want to start listening to
a signal you can.

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Pavel Machek]

Hi!

I do not want to enter seccomp flamewar, and that's why I did not
answer to Ingo.

> > Actually random delays are unlike to help (much). You have just added
> > noise, but you can still decode original signal...
> 
> You're wrong, the random delays added to every packet will definitely
> wipe out any signal.

Strictly speaking, this is wrong. This is like adding noise into the
room. You have to pick up maximum delay (ammount of noise), and you
clearly can't override signal that's longer than maximum delay. But
you also can't override signal that's half the maximum delay, given
that transmitter will retransmit it 4-or-so times. Just average 4
samples, and your random delays will cancel out.

No, this probably does not apply to seccomp, because we are picking
unintended noise from affected computer.

OTOH I'm pretty sure I could communicate from seccomp process by
sending zeros alone, and I cound communicate from another process on
box running seccomp through your randomizing packetizer to my machine.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

On Fri, Jul 14, 2006 at 01:20:26AM +0200, Pavel Machek wrote:
> I do not want to enter seccomp flamewar, and that's why I did not
> answer to Ingo.

Ok ;), I didn't imagine this was the reason. So we agree that the risk
introduced by the availability of the TSC is orders of magnitude
higher than whatever network timing attack.

> Strictly speaking, this is wrong. This is like adding noise into the
> room. You have to pick up maximum delay (ammount of noise), and you
> clearly can't override signal that's longer than maximum delay. But
>
> you also can't override signal that's half the maximum delay, given
> that transmitter will retransmit it 4-or-so times. Just average 4
> samples, and your random delays will cancel out.
> 
> No, this probably does not apply to seccomp, because we are picking
> unintended noise from affected computer.

Well, perhaps I wasn't clear enough, but I am only talking about
seccomp not some other unrelated and hypothetical network system.

I know a few algorithms are potentially vulnerable to network timing
attacks, the tcp sequence number and urandom comes to mind. urandom is
perhaps the worst of all (which btw, it also gets data from the
tsc). Those issues have absolutely nothing to do with seccomp.

As far as seccomp is concerned the only worry is the demonstration of
the timing side channel that was getting openssl keys by controlling
the host and running openssl commands on the other cpu at his
will. And to do that you need the TSC. Even that is totally vapourware
because the attacked environment was strictly controlled by the
attacker, it's unclear what would happen shall the attacked
environment being mostly random like in real life. Disabling the TSC
has been generally agreed good enough to stop it.

The second one in the priority list are the readonly ptes mapping HPET
on some x86-64 config. The network timing attack to CPUShare is way
over what I could actually worry about.

> OTOH I'm pretty sure I could communicate from seccomp process by
> sending zeros alone, and I cound communicate from another process on
> box running seccomp through your randomizing packetizer to my machine.

You mean you could communicate using some sort of morse-code and you
would use the frequency of the zero to send the messages? That's
certainly possible today (without any randomizer), but the timing will
be measurable through the internet, so you're talking morse-code in
cleartext over the internet. The whole internet will sniff your
message. Furthermore I register all ip and ports for all transactions,
so it's really no different from direct a tcp connection even if you
talk encrypted-more-code over it, you're only wasting some resources.

Also note, there's absolutely no way for you to know for sure who you
are talking with.

So I don't see anything to worry about, feel free to communicate with
the other side through seccomp if you want, I'm certainly not adding a
randomizer to prevent that.

Thanks.

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On Fri, 14 Jul 2006 01:11:18 +0200, andrea@cpushare.com said:
> On Thu, Jul 13, 2006 at 09:29:41PM +0000, Pavel Machek wrote:
> > Actually random delays are unlike to help (much). You have just added
> > noise, but you can still decode original signal...
> 
> You're wrong, the random delays added to every packet will definitely
> wipe out any signal.

I call shenanigans on that.

Take a look at the NTP userspace code, which has some very nice code to
filter network jitter. 

In fact, the best you can do here is to reduce the effective bandwidth
the signal can have, as Shannon showed quite clearly.

And even 20 years ago, the guys who did the original DoD Orange Book
requirements understood this - they didn't make a requirement that covert
channels (both timing and other) be totally closed down, they only made
a requirement that for higher security configurations the bandwidth of
the channel be reduced below a specified level...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

On Fri, Jul 14, 2006 at 10:55:28PM -0400, Valdis.Kletnieks@vt.edu wrote:
> In fact, the best you can do here is to reduce the effective bandwidth
> the signal can have, as Shannon showed quite clearly.

Yes.

> And even 20 years ago, the guys who did the original DoD Orange Book
> requirements understood this - they didn't make a requirement that covert
> channels (both timing and other) be totally closed down, they only made
> a requirement that for higher security configurations the bandwidth of
> the channel be reduced below a specified level...

Why I think it's trivial to guarantee the closure of the seccomp side
channel timing attack even on a very fast internet by simply
introducing the random delay, is that below a certain sampling
frequency you won't be able to extract data from the latencies of the
cache. The max length of the random noise has to be >= of what it
takes to refill the whole cache. Then you won't know if it was a cache
miss or a random introduced delay that generated the slowdown, problem
solved.

As you and Pavel correctly pointed out, you can still communicate
whatever you want over the wire (between the two points) by using a
low enough frequency, but I don't think that has security relevance in
this context.

Thanks.

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[Pavel Machek]

> On Fri, Jul 14, 2006 at 10:55:28PM -0400, Valdis.Kletnieks@vt.edu wrote:
> > In fact, the best you can do here is to reduce the effective bandwidth
> > the signal can have, as Shannon showed quite clearly.
> 
> Yes.
> 
> > And even 20 years ago, the guys who did the original DoD Orange Book
> > requirements understood this - they didn't make a requirement that covert
> > channels (both timing and other) be totally closed down, they only made
> > a requirement that for higher security configurations the bandwidth of
> > the channel be reduced below a specified level...
> 
> Why I think it's trivial to guarantee the closure of the seccomp side
> channel timing attack even on a very fast internet by simply
> introducing the random delay, is that below a certain sampling
> frequency you won't be able to extract data from the latencies of the
> cache. The max length of the random noise has to be >= of what it
> takes to refill the whole cache. Then you won't know if it was a
> cache

You won't know for sure... but. Let t be time takes to reload the
cache. Let your random noise be in <0, t> interval. According to you,
that would be okay. IT IS NOT.

If the original delay was long, and your generator returned t,
attacker sees 2*t. He can be _sure_ delay was long now.

If the delay was short, and your generator returns 0, attacker sees 0,
and _knows_ delay was short. (Chance that generator produces 0 or t is
small, but non zero).

Even if you do random noise in <0, 2*t) interval, I'll be able to
gather some statistics.

							Pavel
Thanks, Sharp!

Re: [2.6 patch] let CONFIG_SECCOMP default to n

[andrea]

On Sun, Jul 16, 2006 at 03:54:27AM +0200, Pavel Machek wrote:
> You won't know for sure... but. Let t be time takes to reload the
> cache. Let your random noise be in <0, t> interval. According to you,
> that would be okay. IT IS NOT.
> 
> If the original delay was long, and your generator returned t,
> attacker sees 2*t. He can be _sure_ delay was long now.

Well, it could be a random internet delay that made it 2*t. So you
certainly can't be sure, but I agree you can hope that you were lucky ;).

> If the delay was short, and your generator returns 0, attacker sees 0,
> and _knows_ delay was short. (Chance that generator produces 0 or t
> is

Yes, when you see zero you're sure there was no randomization, but the
zero is what you pay for adding randomization in the first place
(i.e. you need this zero delay for all the other points to become
random).

> small, but non zero).
> 
> Even if you do random noise in <0, 2*t) interval, I'll be able to
> gather some statistics.

And how would those statistic help you in extracting any meaningful
data out of the system? It's like if you've a .wav file completely
random except for a few points that you may guess they could be in
their original position (or close). With a few points scattered
randomly, you won't have any hope to listen to the wav music. It's not
like you're sampling a signal that repeat itself exactly the same
again and again so that you can reconstruct it by mixing the
zero-error points. To make an example when you measure the same point
again, and you won't get 0, you'll never know if it was the
artificial-random delay that made it non-zero, or if the randomizer
was 0 and this time the time measurement was non zero, or if it was a
network delay.

Even you were right that it would be theoretically feasible, at first
glance it sounds easier to crack the ssh key with brute force, than to
try to sniff the private key using your statistics on top of the
randomizer (even ignoring the number of network packets that you would
need to transfer ;).

Now going back to the current server code that doesn't have any
randomizer at all, keep in mind the attack in the paper happened in a
strictly artificial environment (not even close to real life), and the
TSC was used because it takes a nanosecond or so to run, so that you
can measure time at full cpu bandwidth (not at the rate of an
adsl). So if it could take 1 day of sniffing for the guy to extract
anything meaningful with the TSC in real life (which sounds very
unlikely too unless you run ssh in a loop), and you would find a way
to reliably measure the nanoseconds using a millisecond clock (and
here I mean there is no randomizer at all in the system, if I add the
randomizer the whole network attack would fall apart), it would take
you one million of days to sample the same data that the tsc can
sample in one day. And really it's double RTT because it's not a pure
p2p, and it'll be more likely in the order of 20msec if you're both an
adsl. That change alone will raise the time from 1 million days to 20
million days. Not only this assumes no randomizer, this also doesn't
account in any way the several repetition of measurements required to
apply ntp-like algorithms which would explode the number of days to
orders of magnitude bigger than the 1-20 million days mentioned above.

All the above considerations should be combined with the fact that a
CPUShare transaction takes 1 hour, not 1-20 million days. Once the
transaction is complete you will never know who you attach with next
time, so after one hour passes, your above statistic would be sampling
a different ssh private key, not the same one.

No matter from what point of view you revolt the problem, the network
attack sounds the least thing I could be concerned about, attacks
against urandom for the ssh private key generation sounds more likely
than this one.

And if somebody attempts this kind of attack, I'll be noticing with
the network bill ;). Once my network bill will be high enough I may
decide to add the randomizer just in case. The sell orders could have
network quotas as well in the future, so a seller can specify the max
amount of network data he accepts to transfer during the transaction
to be more secure and to generate less network traffic spread over the
hour of computations (so he can still leave a good portion of his adsl
free to surf or run other p2p software).

Last but not the least, completely closing the cache timing side
channel is possible if I wanted to by simply invalidate the whole l2
cache in the same place were I flip the cr4 (plus a change of the
scheduler to forbid seccomp and non-seccomp tasks to mix in the same
physical cpu). It's just not worth it.

While I want the best security available in the basic computing mode
supported by all clients (i.e. seccomp), CPUShare is very clear that
any exposure of confidential data through the internet, or any other
damage like spread of troyans, spyware, adware or viruses is at your
risk. While I'm convinced the network timing attack is a total
hogwash, CPU bugs are very possible, kernel bugs are very possible
too, those are orders of magnitude likely to be exploitable than
whatever network timing attack. No matter what technology I use,
everything can be buggy at both the hardware and software layer, even
the math itself of the crypto could have been proven wrong. There's no
way for me to provide any guarantee, the kernel itself is under the
GPL with no warranty, and so is seccomp under the GPL and with no
warranty too. I only can guarantee that I'm doing my best for anything
that makes sense (i.e. the tsc, since the tsc being so fast [and so
accurate too], million times more risky than whatever remote
clock). Worrying about the TSC sounds paranoid enough already,
worrying about the network attack is just way over I can consider to
have practical security relevance as of 2006 internet network
bandwidth and latency in connection with the current CPUShare code. As
I said I'd be glad to check again 10 years from now in the hope
latencies will go down to the usec and bandwidth up to the gigabits
like I strongly hope.

If you don't believe me and you want to be sure, feel free to add a
seccomp mode that flushes the cache at every context switch from
non-seccomp to seccomp plus the HT hack as I suggested above. You
don't have to trust me, all code that runs on your computer is free
software and not covered by any pending-patent at all, so you can
change it as you want, though if it was me I wouldn't do that since I
don't like to run slow for no apparent good reason.

If you've more doubts please feel free to go ahead, but I recommend to
move this thread on the security attacks on cpushare-devel mailing
list. This is way offtopic here (I'm answering in CC just to express
my point of view on the matter, but I don't think it's much relevant
for this list).

Thanks Pavel.