Re: [patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

* Andi Kleen <ak@xxxxxxx> wrote:

> On Wednesday 12 July 2006 23:07, Ingo Molnar wrote:
> > 
> > * Andi Kleen <ak@xxxxxxx> 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. [...]

(certainly - that's why i added the 'almost' qualifier to '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.)
> 
> 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.

yeah. But wouldnt it be nicer to have the same damn thing that also 
improves a vital infrastructure of Linux, namely ptrace? Andrea didnt 
even try to improve ptrace - in fact he actively (and mostly unfairly) 
attacked ptrace, implicitly weakening the security perception of other 
syscall filtering based projects like User Mode Linux. Now what we have 
is the same old ptrace, some context-switch overhead, ~900 bytes of 
bloat and a NIH API. It's a lose-lose scenario IMO ...

> > 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, [...]

Andrea wrote:

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

see:

 http://marc.theaimsgroup.com/?l=linux-kernel&m=115167947608676&w=2

> [...] but I would generally trust Andrea not to attempt to do anything 
> evil regarding kernel & patents.

firstly, you might trust Andrea, but do you trust the entity that 
actually owns the patent (cpushare.com and its investors)? And even if 
you trusted Andrea, would you trust his heir(s)?

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

please do.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/