Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen <ak@suse.de>]

On Wednesday 12 July 2006 23:07, Ingo Molnar wrote:
> 
> * 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)

I wouldn't call it completely hogwash - there was a published paper
with a demo of an attack - but still the attack required to so much
preparation and advance knowledge of the system that it seemed
more of academical value to me. At least for the standard kernel
we chose to not care about it. So for seccomp it was also not needed
imho.

> 
> 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.)

I think without the context switch overhead it's a moderately useful facility.
Ok currently near nobody uses it, but having a very lightweight sandbox
with simple security semantics and that's easy to use is a useful 
facility for more secure user space.

It certainly would need to be better advertised to be any useful.
e.g. with a simple user space library that makes it easy to use.

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

I don't know any details about this, but I would generally trust Andrea not to
attempt to do anything evil regarding kernel & patents.

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

I can put in a patch into my tree for the next merge to disable the TSC
disable code on i386 too like I did earlier for x86-64.

I don't have a great opinion on the Kconfig defaults, so I won't put
in a patch for that.

-Andi