lkml.org 
[lkml]   [2006]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] let CONFIG_SECCOMP default to n

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

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

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

\
 
 \ /
  Last update: 2006-07-13 00:27    [W:0.091 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site