Re: [patch] let CONFIG_SECCOMP default to n

Re: [patch] let CONFIG_SECCOMP default to n

[Albert Cahalan]

Linus Torvalds writes:

> I don't think SECCOMP is wrong per se, but I do believe that
> if other approaches become more popular, and the only user of
> SECCOMP is not GPL'd and uses some patented stuff, then we should
> seriously look at the other interfaces (eg the extended ptrace).
>
> Does anybody actually really _use_ SECCOMP outside of the
> patented stuff?

I write debugger code. I can not possibly express how broken
the ptrace interface is. There are numerous corner conditions
that it gets terribly wrong. If you single step over any
"interesting" instructions, if the target plays funny games
with signals or the trap flag...

The utrace stuff offers some hope for eventually fixing this
mess. Please accept that or something similar.

As for SECCOMP... non-root users need high-performance ways
to sandbox things. I do not believe that one solution fits all.
Perhaps SE Linux could be extended to let users sub-divide
their accounts, and certainly ptrace could be made better.

SECCOMP is a good idea, but currently a tad too limiting.
There are a few dozen system calls that would be safe and useful,
particularly those related to signals, memory, and synchronization.

I see no reason to have a config option outside of
CONFIG_EMBEDDED. Ditch the TSC stuff though.

Re: utrace vs. ptrace

[Ingo Molnar]

* Albert Cahalan <acahalan@gmail.com> wrote:

> The utrace stuff offers some hope for eventually fixing this mess. 
> Please accept that or something similar.

yeah. Much of the API and usage problems of ptrace stem from its (mostly 
artificial) coupling to signals (and other, mostly historical baggage).

utrace gets rid of all of that baggage and artificial coupling! The 
utrace patchset first rips out all of ptrace (completely!), then adds 
utrace (which is in essence the CPU state fiddling bits of ptrace), then 
adds the ptrace API as an utrace module. It really doesnt get cleaner 
than that. See:

  http://people.redhat.com/roland/utrace/0-intro.txt

and:

  http://people.redhat.com/roland/utrace/

for the actual code.

utrace enables exciting things like a global crash-handling daemon that 
can collect live info from crashing (segfaulting) apps transparently, 
_without_ having all apps in the system ptraced in advance!

One of the biggest QA problems Linux has is that we very frequently lose 
information about the 'first incidence of crashing'. [Some of the GUIs 
have automatic crash-reporting, but those solutions are obviously 
limited to those GUIs and they dont use ptrace and have various 
shortcomings.]

utrace enables something like 'transparent live debugging': an app 
crashes in your distro, a window pops up, and you can 'hand over' a 
debugging session to a developer you trust. Or you can instruct the 
system to generate a coredump. Or you can generate a shorter summary of 
the crash, sent to a central site.

utrace enables the distro to automatically (and transparently) download 
debuginfo packages of an app that segfaults so that next time the crash 
happens there's better info to debug it - without the user having to 
bother about this.

utrace enables multiple debugging infrastructures being attached to the 
same task.

and last but not least, utrace enables the prototyping of debuging 
infrastructure without having to revamp the kernel APIs all the time.

Even if i wanted i couldnt over-hype utrace: it is by far the most 
important thing that happened to ptrace (and Linux debugging in general) 
in the past 10 years or so.

	Ingo

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

Hello,

On Thu, Jul 13, 2006 at 01:43:42AM -0400, Albert Cahalan wrote:
> SECCOMP is a good idea, but currently a tad too limiting.
> There are a few dozen system calls that would be safe and useful,
> particularly those related to signals, memory, and synchronization.

malloc/free can be emulated in userland so that's not a big
problem. All the rest is a problem instead, unmodified software just
won't run.

seccomp mode 1 is the absolute minimum you need to compute ;). Every
single syscall we add it gets less secure. Several exploits happened
in mremap for example, even if at first glance it may sound a safe
syscall. It's safe now, but it may get buggy again later as new
features are being added.

I'd be skeptical adding seccomp mode 2 with more syscalls, otherwise
it's better to make it more flexible and to specify the syscalls to
allow from userland (which I'm not against if you've usages for it).

>From my part to go beyond seccomp, as jail for the interpreters I'll
probably use virtualization like ourgrid and tycoon (seccomp is the
safest and simplest mode but there's simply no way to run an
interpreter under it ;).

Re: utrace vs. ptrace

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> utrace enables something like 'transparent live debugging': an app 
> crashes in your distro, a window pops up, and you can 'hand over' a 
> debugging session to a developer you trust. Or you can instruct the 
> system to generate a coredump. Or you can generate a shorter summary 
> of the crash, sent to a central site.

not to mention that utrace could be used to move most of the ELF 
coredumping code out of the kernel. (the moment you have access to all 
crashed threads userspace can construct its own coredump - instead of 
having the kernel construct a coredump file) Roland's patch does not go 
as far yet, but it could be a possible target.

	Ingo

Re: utrace vs. ptrace

[Andi Kleen]

On Thursday 13 July 2006 11:24, Ingo Molnar wrote:
> * Ingo Molnar <mingo@elte.hu> wrote:
> > utrace enables something like 'transparent live debugging': an app
> > crashes in your distro, a window pops up, and you can 'hand over' a
> > debugging session to a developer you trust. Or you can instruct the
> > system to generate a coredump. Or you can generate a shorter summary
> > of the crash, sent to a central site.
>
> not to mention that utrace could be used to move most of the ELF
> coredumping code out of the kernel. (the moment you have access to all
> crashed threads userspace can construct its own coredump - instead of
> having the kernel construct a coredump file) Roland's patch does not go
> as far yet, but it could be a possible target.

I'm not sure that's particularly useful (I think I would prefer to keep
it in kernel), but executing a program when a core dump happens is useful with 
lots of applications.  I had patches for this
that i should probably submit at some point.


-Andi

> 	Ingo

Re: utrace vs. ptrace

[Ingo Molnar]

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

> On Thursday 13 July 2006 11:24, Ingo Molnar wrote:
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > > utrace enables something like 'transparent live debugging': an app
> > > crashes in your distro, a window pops up, and you can 'hand over' a
> > > debugging session to a developer you trust. Or you can instruct the
> > > system to generate a coredump. Or you can generate a shorter summary
> > > of the crash, sent to a central site.
> >
> > not to mention that utrace could be used to move most of the ELF
> > coredumping code out of the kernel. (the moment you have access to all
> > crashed threads userspace can construct its own coredump - instead of
> > having the kernel construct a coredump file) Roland's patch does not go
> > as far yet, but it could be a possible target.
> 
> I'm not sure that's particularly useful (I think I would prefer to 
> keep it in kernel), [...]

why would we want to keep this in the kernel? Coredumping in the kernel 
is fragile, and it's nowhere near performance-critical to really live 
within the kernel.

	Ingo

Re: utrace vs. ptrace

[Andi Kleen]

> > I'm not sure that's particularly useful (I think I would prefer to 
> > keep it in kernel), [...]
> 
> why would we want to keep this in the kernel? Coredumping in the kernel 
> is fragile, and it's nowhere near performance-critical to really live 
> within the kernel.

Mostly because I fear it would become another udev like disaster, requiring user 
space updates regularly, and core dumps are a fairly critical debugging feature
that I wouldn't like to become unreliable.

That said extended core dumping (e.g. automatic processing of the output) 
in user space makes sense. I had a prototype for that once that uploaded
a simple crash report to a web page.

-Andi

Re: utrace vs. ptrace

[Arjan van de Ven]

> That said extended core dumping (e.g. automatic processing of the output) 
> in user space makes sense. I had a prototype for that once that uploaded
> a simple crash report to a web 

the script I use for that is at
http://www.fenrus.org/bt.sh

it tries to include things like rpm versions of the package it was in
etc, and suggests/downloads the right debuginfo rpms to improve the
backtrace. Clearly that's all userspace stuff; but it can run from a
daemon easily; eg have all core dumps go to a special directory where
the daemon reaps them and analyzes.

Re: utrace vs. ptrace

[Andi Kleen]

On Thursday 13 July 2006 15:28, Arjan van de Ven wrote:
> 
> > That said extended core dumping (e.g. automatic processing of the output) 
> > in user space makes sense. I had a prototype for that once that uploaded
> > a simple crash report to a web 
> 
> the script I use for that is at
> http://www.fenrus.org/bt.sh
> 
> it tries to include things like rpm versions of the package it was in
> etc, and suggests/downloads the right debuginfo rpms to improve the
> backtrace. Clearly that's all userspace stuff; but it can run from a
> daemon easily; eg have all core dumps go to a special directory where
> the daemon reaps them and analyzes.

You can't do that right now because core_pattern doesn't support slashes.
The coredumps will be always all over the fs or not be there at all
if the cwd is write protected.

In my patch I allowed pipes and piped the coredump into a user space
processor that generated a simple report using gdb and sent it off.

The web frontend then did some statistics on what crashed most.

-Andi

Re: utrace vs. ptrace

[Arjan van de Ven]

On Thu, 2006-07-13 at 15:34 +0200, Andi Kleen wrote:
> On Thursday 13 July 2006 15:28, Arjan van de Ven wrote:
> > 
> > > That said extended core dumping (e.g. automatic processing of the output) 
> > > in user space makes sense. I had a prototype for that once that uploaded
> > > a simple crash report to a web 
> > 
> > the script I use for that is at
> > http://www.fenrus.org/bt.sh
> > 
> > it tries to include things like rpm versions of the package it was in
> > etc, and suggests/downloads the right debuginfo rpms to improve the
> > backtrace. Clearly that's all userspace stuff; but it can run from a
> > daemon easily; eg have all core dumps go to a special directory where
> > the daemon reaps them and analyzes.
> 
> You can't do that right now because core_pattern doesn't support slashes.
> The coredumps will be always all over the fs or not be there at all
> if the cwd is write protected.

are you sure? I had this working in the 2.6.9 timeframe, I could set
core pattern to /tmp/corefiles/core and such just fine..
(and the core files ended up in the /tmp/corefiles/ directory as well)

Re: utrace vs. ptrace

[Andi Kleen]

> are you sure? I had this working in the 2.6.9 timeframe, I could set
> core pattern to /tmp/corefiles/core and such just fine..
> (and the core files ended up in the /tmp/corefiles/ directory as well)

Hmm, yes maybe it has changed. When I tried it originally (which was before 2.6.9)
it didn't work

-Andi

Re: utrace vs. ptrace

[Linus Torvalds]

On Thu, 13 Jul 2006, Andi Kleen wrote:

> 
> > > I'm not sure that's particularly useful (I think I would prefer to 
> > > keep it in kernel), [...]
> > 
> > why would we want to keep this in the kernel? Coredumping in the kernel 
> > is fragile, and it's nowhere near performance-critical to really live 
> > within the kernel.
> 
> Mostly because I fear it would become another udev like disaster, requiring user 
> space updates regularly, and core dumps are a fairly critical debugging feature
> that I wouldn't like to become unreliable.

Doing core-dumping in user space would be insane. It doesn't give _any_ 
advantages, only disadvantages.

Why do people keep thinking that doing things in user space is "safer" and 
"easier". It's quite often not. For example, all the "fragile" stuff would 
be true for a user-space dumper (don't tell me it's safer - it would 
obviously have to run with elevated capabilities), and a lot of it would 
be a hell of a lot harder.

		Linus

Re: utrace vs. ptrace

[Ingo Molnar]

* Linus Torvalds <torvalds@osdl.org> wrote:

> > Mostly because I fear it would become another udev like disaster, 
> > requiring user space updates regularly, and core dumps are a fairly 
> > critical debugging feature that I wouldn't like to become 
> > unreliable.
> 
> Doing core-dumping in user space would be insane. It doesn't give 
> _any_ advantages, only disadvantages.

well, it was just a quick idea of mine that looked nice in the following 
sense: it would reuse (and thus test) debugging infrastructure that we 
want to and have to provide anyway. (if gdb is attached to a task that 
crashes then it is in a position to get all the information to create a 
coredump)

it wouldnt be fundamentally easier - but lots of policy stuff could be 
done there which we would otherwise reject to add to the kernel. Like 
more complex rules for "do we want to dump core for this particular 
app".

> Why do people keep thinking that doing things in user space is "safer" 
> and "easier". It's quite often not. For example, all the "fragile" 
> stuff would be true for a user-space dumper (don't tell me it's safer 
> - it would obviously have to run with elevated capabilities), and a 
> lot of it would be a hell of a lot harder.

It would have to run with privileges enough to 1) get the process/thread 
state [but not set it] 2) to write the resulting coredump to some file.

You are right that if we make it privileged enough to implement #2 as 
"put the coredump into the apps cwd, with the user's identity", that 
would expose this privileged code to similar file-permission security 
problems as the in-kernel dumper.

But if #2 is implemented in a more restricted way (like coredumps only 
go to a central directory not accessible to users, are size-limited, are 
fingerprinted for their backtraces to remove duplicates, are matched to 
an online repository of already reported bugs, etc.) then it could be 
more secure than the in-kernel dumper - just because it would do less. 
(and it would also do more, in a sense)

but ... i agree that it's not an "obvious win", and that it can create a 
less secure solution than the in-kernel dumper. Although the in-kernel 
dumper doesnt have a stellar security track record, so the quality bar 
isnt particularly high :-/

	Ingo

Re: utrace vs. ptrace

[Paul Jackson]

Ingo wrote:
> it wouldnt be fundamentally easier - but lots of policy stuff could be 
> done there which we would otherwise reject to add to the kernel. Like 
> more complex rules for "do we want to dump core for this particular 
> app".

Reading this brought to mind the 'user exit' hooks that are common
in IBM's mainframe O.S.'s.

Their system code does what system code does (and likely a whole lot
more than Linux would consider doing.)  But they also provide many
places for user level code to get called off a variety of hooks,
to allow for special cases.

I had fantasies of our core dumping code using call_usermodehelper()
to call a user command by a well known path, passing it the pid of
the corpse.  While waiting for the user command to exit, the kernel
would accept non-default core dump settings via special /sys or /proc
files for that pid.  The user mode helper command could set these
options before returning (by exiting) to the kernel for the core dump
to be processed.  By default, the user command would do nothing but
exit and the core dump would proceed as it does now.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: utrace vs. ptrace

[Linus Torvalds]

On Tue, 25 Jul 2006, Alan Cox wrote:
>
> On Iau, 2006-07-13 at 12:05 -0700, Linus Torvalds wrote:
> > Doing core-dumping in user space would be insane. It doesn't give _any_ 
> > advantages, only disadvantages.
> 
> It has a number of very real advantages in certain circumstances and the
> only interface the kernel needs to provide is the debugger interface and
> something to "kick" the debugger and reparent to it, or for that matter
> it might even be viable just to pass the helper the fd of an anonymous
> file holding the dump.

What you're talking about is not core-dumping, it's just an extended 
debugging interface. And it eeds to be _damn_ careful, exactly because it 
tends to be something very security-sensitive.

> Taking out the kernel core dump support would be insane.

Indeed.

> We get customers who like to collect/process/do clever stuff with core
> dumps and failure cases. We also get people who want to dump a core that
> excludes the 14GB shared mmap of the database file as another example
> where it helps.

"ptrace" certainly isn't wondeful.

What you often want is not a core-dump at all, but a "stop the process" 
thing. It's really irritating that the core-dump is generated and the 
process is gone, when it would often be a lot nicer if instead of 
core-dumping, the process was just stopped and then you could attach to it 
with gdb, and get the whole damn information (including things like access 
to open file descriptors etc).

But again, that has nothing to do with core-dumping. 

			Linus

Re: utrace vs. ptrace

[Alan Cox]

On Iau, 2006-07-13 at 12:05 -0700, Linus Torvalds wrote:
> Doing core-dumping in user space would be insane. It doesn't give _any_ 
> advantages, only disadvantages.

It has a number of very real advantages in certain circumstances and the
only interface the kernel needs to provide is the debugger interface and
something to "kick" the debugger and reparent to it, or for that matter
it might even be viable just to pass the helper the fd of an anonymous
file holding the dump.

Taking out the kernel core dump support would be insane.

We get customers who like to collect/process/do clever stuff with core
dumps and failure cases. We also get people who want to dump a core that
excludes the 14GB shared mmap of the database file as another example
where it helps.

Alan

Re: utrace vs. ptrace

[Olaf Hering]

 On Tue, Jul 25, Linus Torvalds wrote:

> What you often want is not a core-dump at all, but a "stop the process" 
> thing. It's really irritating that the core-dump is generated and the 
> process is gone, when it would often be a lot nicer if instead of 
> core-dumping, the process was just stopped and then you could attach to it 
> with gdb, and get the whole damn information (including things like access 
> to open file descriptors etc).
> 
> But again, that has nothing to do with core-dumping. 

It would be helpful to have that sort of functionality in mainline.
Would a patch be acceptable that sends SIGSTOP instead of SIGSEGV or
SIGILL if some knob was enabled, either global or per process?

Re: utrace vs. ptrace

[Ingo Molnar]

* Olaf Hering <olh@suse.de> wrote:

>  On Tue, Jul 25, Linus Torvalds wrote:
> 
> > What you often want is not a core-dump at all, but a "stop the process" 
> > thing. It's really irritating that the core-dump is generated and the 
> > process is gone, when it would often be a lot nicer if instead of 
> > core-dumping, the process was just stopped and then you could attach to it 
> > with gdb, and get the whole damn information (including things like access 
> > to open file descriptors etc).
> > 
> > But again, that has nothing to do with core-dumping. 
> 
> It would be helpful to have that sort of functionality in mainline. 
> Would a patch be acceptable that sends SIGSTOP instead of SIGSEGV or 
> SIGILL if some knob was enabled, either global or per process?

FYI, the sample utrace module from Roland does precisely that, it stops 
a task on crash... See more at:

  http://people.redhat.com/roland/utrace/

- crash-suspend.c is the sample module.

- ntrace-0.0.2.tar.bz2 is an extensive ptrace and utrace functionality 
  testsuite.

	Ingo

Re: utrace vs. ptrace

[Martin Bligh]

Alan Cox wrote:
> On Iau, 2006-07-13 at 12:05 -0700, Linus Torvalds wrote:
> 
>>Doing core-dumping in user space would be insane. It doesn't give _any_ 
>>advantages, only disadvantages.
> 
> 
> It has a number of very real advantages in certain circumstances and the
> only interface the kernel needs to provide is the debugger interface and
> something to "kick" the debugger and reparent to it, or for that matter
> it might even be viable just to pass the helper the fd of an anonymous
> file holding the dump.
> 
> Taking out the kernel core dump support would be insane.
> 
> We get customers who like to collect/process/do clever stuff with core
> dumps and failure cases. We also get people who want to dump a core that
> excludes the 14GB shared mmap of the database file as another example
> where it helps.

The in-kernel core dumper also seems to hold locks that wedge access
to /proc for that pid, which causes anything walking /proc to wedge.
For large core dumps, that takes far too long, and causes us real
problems

M.

Re: [patch] let CONFIG_SECCOMP default to n

[Bodo Eggert]

Ingo Molnar <mingo@elte.hu> wrote:
> * Jeff Dike <jdike@addtoit.com> wrote:

>> Now, there were a couple of ways to legitimately escape from UML, and
>> they *did* involve ptrace.  Things like single-stepping a system call
>> instruction or putting a breakpoint on a system call instruction and
>> single-stepping from the breakpoint.  As far as I know, these were
>> discovered and fixed by UML developers before there was any outside
>> awareness of these bugs.
> 
> also, UML 'ptrace clients' are allowed alot more leeway than what a
> seccomp-alike ptrace/utrace based syscall filter would allow. It would
> clearly exclude activities like 'setting a breakpoint' or
> 'single-stepping' - valid syscalls would be limited to
> read/write/sigreturn/exit.

So instead of breakpointing (using int3), you'd have to write
'mv flag I_AM_HERE;self:jmp self' and resort to polling?
This would not prevent (ab)use except for some corner cases.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html

Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen]

On Thursday 13 July 2006 03:51, Andrew Morton wrote:
> On Wed, 12 Jul 2006 23:07:32 +0200
>
> Ingo Molnar <mingo@elte.hu> wrote:
> > Despite good resons to apply the patch, it has not been applied yet,
> > with no explanation.
>
> I queued the below.  Andrea claims that it'll reduce seccomp overhead to
> literally zero.

Chuck's patch - possibly with Linus' rename - is better.

-Andi

Re: [patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

* Jeff Dike <jdike@addtoit.com> wrote:

> Now, there were a couple of ways to legitimately escape from UML, and 
> they *did* involve ptrace.  Things like single-stepping a system call 
> instruction or putting a breakpoint on a system call instruction and 
> single-stepping from the breakpoint.  As far as I know, these were 
> discovered and fixed by UML developers before there was any outside 
> awareness of these bugs.

also, UML 'ptrace clients' are allowed alot more leeway than what a 
seccomp-alike ptrace/utrace based syscall filter would allow. It would 
clearly exclude activities like 'setting a breakpoint' or 
'single-stepping' - valid syscalls would be limited to 
read/write/sigreturn/exit.

	Ingo

Re: [patch] let CONFIG_SECCOMP default to n

[Jeff Dike]

On Thu, Jul 13, 2006 at 05:16:14AM +0200, Andrea Arcangeli wrote:
> On Thu, Jul 13, 2006 at 12:19:11AM +0200, Ingo Molnar wrote:
> > attacked ptrace, implicitly weakening the security perception of other 
> > syscall filtering based projects like User Mode Linux. Now what we have 
> 
> Note that UML had a security weakness already that allowed to escape
> the jail, see bugtraq. Infact his complexity is huge regardless of
> ptrace, the security hole probably wasn't even ptrace related (I don't
> remember the exact details).

Not hardly.  If you did remember the exact details, you'd remember
that it was in 2000, and someone "discovered" that tt mode didn't
allow kernel memory to be protected from userspace.  It had always
been well documented that tt mode had this problem and you shouldn't
be using it if you needed a secure VM.

See http://www.securityfocus.com/bid/3973/info

Now, there were a couple of ways to legitimately escape from UML, and
they *did* involve ptrace.  Things like single-stepping a system call
instruction or putting a breakpoint on a system call instruction and
single-stepping from the breakpoint.  As far as I know, these were
discovered and fixed by UML developers before there was any outside
awareness of these bugs.

				Jeff

Re: [patch] let CONFIG_SECCOMP default to n

[Andrew Morton]

On Thu, 13 Jul 2006 10:34:41 +0200
andrea@cpushare.com wrote:

> Both patches are obsoleted by the new logic in the context switch that
> uses the bitflags to enter the slow path, see Chuck's patch.

What darn patch?

<looks>

hm, p73wtain80h.fsf@verdi.suse.de, who appears to be Andi has (again)
removed me from cc.  Possibly an act of mercy ;)

> As long as seccomp won't be nuked from the kernel, Chuck's patch seems
> the way to go.

I see "[compile tested only; requires just-sent fix to i386 system.h]", so
an appropriate next step would be for you to review, test, sign-off and
forward it, please.

> But the point is that I've no idea anymore what will happen to
> seccomp so perhaps all patches will be useless.

Shrug.  If we can optimise the current code, fine.  If there's a default-on
config option that makes no-TSC seccomp have zero overhead, better.  If that
makes us go back to doing useful stuff, perfect.

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

On Thu, Jul 13, 2006 at 03:44:38AM -0400, James Bruce wrote:
> Andrea,
> what happened to Andrew James Wade's rewording [1] of your config help? 
>   It seemed to disappear from what was submitted to akpm.

Andrew picked the patch I made originally, before Andrew James Wade
patched it.

Both patches are obsoleted by the new logic in the context switch that
uses the bitflags to enter the slow path, see Chuck's patch. That will
prevent the need of a config option because it's zero cost like the
core of seccomp.

As long as seccomp won't be nuked from the kernel, Chuck's patch seems
the way to go.

But the point is that I've no idea anymore what will happen to
seccomp so perhaps all patches will be useless.

Re: [patch] let CONFIG_SECCOMP default to n

[James Bruce]

Andrew Morton wrote:
> On Wed, 12 Jul 2006 23:07:32 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
>> Despite good resons to apply the patch, it has not been applied yet, 
>> with no explanation.
> 
> I queued the below.  Andrea claims that it'll reduce seccomp overhead to
> literally zero.
> 
> But looking at it, I think it's a bit confused.  The patch needs
> s/DISABLE_TSC/ENABLE_TSC/ to make it right.
<-- snip -->

Andrea,
what happened to Andrew James Wade's rewording [1] of your config help? 
   It seemed to disappear from what was submitted to akpm.

To "mathematically prevent covert channels" is far too strong a claim to 
make, since you only handle the case of TSC-related timing attacks. 
AJW's wording is much better, so please don't drop it.

Of course, if the new wording will be included in some forthcoming patch 
that also makes Linus happy [2], then never mind.

  - Jim Bruce

[1] http://lkml.org/lkml/2006/7/10/440
[2] http://lkml.org/lkml/2006/7/12/328

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

On Wed, Jul 12, 2006 at 10:12:15PM -0700, Linus Torvalds wrote:
> You're just in denial, and don't even listen to what people say. It also 
> has nothing to do with cpufreq, which again is a case of _some_ uses may 
> be patented, but not "_the_ use"

You know "_the_ only use" possible of transmeta.o (see the function
init_transmeta) is in connection with the CMS patented software:

	/* Print CMS and CPU revision */
	max = cpuid_eax(0x80860000);

If you can see a difference between transmeta.o and seccomp.o then I
trust you but personally the only difference I can see is that with
seccomp.o it is possible that it will be used for something else
useful too.

I never cared about transmeta.o being linked into my kernels despite I
never happened to need it so far in my life and despite it's larger
than seccomp. I'm happy to spend those hundred bytes in the transmeta
code just in case I would become a transmeta user in the future.

> I just stated that if other interfaces don't have the problem that
> their only use is patent-protected, then other interfaces are
> clearly better alternatives. IF they have users at all.

Obviously you're free to change the kernel the way you want (feel free
to nuke seccomp as well if you want), but I'm also free not to switch
to ptrace if the only reason you give me is sadly non-technical. If
seccomp is better, it is better regardless if the server side is
patent-pending (not patent-protected) or not. So even trusting you
that transmeta.o is fundamentally different from seccomp.o, and it's
all fair as you imply, it still won't make a difference to me since I
only care about technical arguments for my decisions about CPUShare.

Re: [patch] let CONFIG_SECCOMP default to n

[Linus Torvalds]

On Thu, 13 Jul 2006, Andrea Arcangeli wrote:
> 
> But there may be some users only using alsa to play mp3, so it's not
> so different (certainly I agree if it would be nice if there would be
> more users since it can solve the codec decompression exploits).

You aren't even listening.

> If what you don't like is the API and you want to change it (like
> replacing the /proc interface with a syscall or a prctl) that's fine
> with me though.

This has NOTHING to do with the API.

You're just in denial, and don't even listen to what people say. It also 
has nothing to do with cpufreq, which again is a case of _some_ uses may 
be patented, but not "_the_ use"

I just stated that if other interfaces don't have the problem that their 
only use is patent-protected, then other interfaces are clearly better 
alternatives. IF they have users at all.

			Linus

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

I sent the previous email from suse.de but like for the previous
emails in this thread, I was only speaking for myself. I followup
myself to specify this explicitly because if I did any major or minor
mistake in my reasoning in this thread, I want to be clear that you
must only blame me personally. The previous from got automatically
caught up by the reply headers.

Re: [patch] let CONFIG_SECCOMP default to n

[Andrea Arcangeli]

On Wed, Jul 12, 2006 at 08:12:16PM -0700, Linus Torvalds wrote:
> ALSA is used for other things _too_.

But there may be some users only using alsa to play mp3, so it's not
so different (certainly I agree if it would be nice if there would be
more users since it can solve the codec decompression exploits).

> I don't think SECCOMP is wrong per se, but I do believe that if other 
> approaches become more popular, and the only user of SECCOMP is not GPL'd 
> and uses some patented stuff, then we should seriously look at the other 
> interfaces (eg the extended ptrace).

You want to extend ptrace so I can run two ptraces of the same ptraced
task? (one to stop the syscalls from happening like current seccomp
does, the other to debug the task with gdb while it's under the first
ptrace?) I think Linux will be better off without this complication
(and I'll be better off too, I've enough paralleism to deal with
already in this project without this one more ;)

If what you don't like is the API and you want to change it (like
replacing the /proc interface with a syscall or a prctl) that's fine
with me though.

> Does anybody actually really _use_ SECCOMP outside of the patented
> stuff?

Just a side note, it's patent-pending, not patented. It may never be
patented infact, all these discussion sounds very premature to me.

About your question, does it really matter what I would answer, given
we already have code in the kernel that can only be used in
combination with patented software and that it isn't useful for
anything else?

config X86_LONGRUN
        tristate "Transmeta LongRun"
        help
          This adds the CPUFreq driver for Transmeta Crusoe and Efficeon processors
          which support LongRun.

          For details, take a look at <file:Documentation/cpu-freq/>.

          If in doubt, say N.

Both these files:

     linux-2.6/arch/i386/kernel/cpu/cpufreq/longrun.c
     linux-2.6/arch/i386/kernel/cpu/transmeta.c

are only useful if used in comination with the CMS patented software
(Combining hardware and software to provide an improved
microprocessor):

     http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=50&f=G&l=50&co1=AND&d=PTXT&s1=transmeta.ASNM.&OS=AN/transmeta&RS=AN/transmeta

Furthermore the transmeta.o generates a 2964 bytes object, and cannot
be set to N, so it's linked in all i386 kernels out there, seccomp.o
OTOH can be set to N generating zero bytes of overhead and its final
.o size is 1108 bytes.

If you are aware of any other use of the above two files other than
the patented stuff you probably may want to communicate it to
Transmeta cause I guess they would be interested to know.

Re: [patch] let CONFIG_SECCOMP default to n

[Andrea Arcangeli]

On Thu, Jul 13, 2006 at 12:19:11AM +0200, Ingo Molnar wrote:
> attacked ptrace, implicitly weakening the security perception of other 
> syscall filtering based projects like User Mode Linux. Now what we have 

Note that UML had a security weakness already that allowed to escape
the jail, see bugtraq. Infact his complexity is huge regardless of
ptrace, the security hole probably wasn't even ptrace related (I don't
remember the exact details).

I'm a big fun of UML and other userland virtualization project, my own
ex prof is working on a few of them. That doesn't mean I would use UML
as a jail myself for CPUShare.

In the last two years of existence of seccomp, there has never been a
single bug that could allow to escape the jail, infact there has never
been one that I know if you backtest seccomp. And this track record
will continue.

Even the kernel itself as a whole is less secure than the seccomp
jail, that doesn't mean I want to weaken the perception of anything.
It's a pure matter of probability, the higher the complexity and the
bigger is the size of the project in kernel space, the more likely
there can be bug that can lead to an exploit.

Re: [patch] let CONFIG_SECCOMP default to n

[Linus Torvalds]

On Thu, 13 Jul 2006, Andrea Arcangeli wrote:
> 
> What Ingo complains about is the fact somebody could be selling a
> patented mp3 player that uses alsa. Should alsa be rejected from the
> kernel? Does that mean alsa has anything to do with the mp3 patent?

ALSA is used for other things _too_.

I don't think SECCOMP is wrong per se, but I do believe that if other 
approaches become more popular, and the only user of SECCOMP is not GPL'd 
and uses some patented stuff, then we should seriously look at the other 
interfaces (eg the extended ptrace).

Does anybody actually really _use_ SECCOMP outside of the patented stuff?

		Linus

Re: [patch] let CONFIG_SECCOMP default to n

[Andrea Arcangeli]

On Thu, Jul 13, 2006 at 12:06:12AM +0200, Andi Kleen wrote:
> I don't know any details about this, but I would generally trust Andrea not to
> attempt to do anything evil regarding kernel & patents.

I appreciate Andi.

For the ones that don't seem to trust me I quote Alan (and I also know
that what Alan said is correct):

  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.

What Ingo complains about is the fact somebody could be selling a
patented mp3 player that uses alsa. Should alsa be rejected from the
kernel? Does that mean alsa has anything to do with the mp3 patent?

Another example is when you make a search on google.com, you use the
tcp/ip kernel stack to connect to a software covered by
patents. Should the tcp/ip stack be removed from the kernel? Does that
mean that the tcp/ip code has anything to do with the google patents?

Yes I also use tcp/ip, so do you want to reject tcp/ip from the kernel
to prevent people to run the software that connects the seccomp task
to the server? seccomp alone won't allow the client software to work
unless I can connect to the server, so tcp/ip is guilty exactly the
same way as seccomp.

There are infinite other examples...

About the GPL, I'm a huge believer on the GPL, I said multiple times I
think Linux has got the success it has because it's under the GPL and
not under the BSD. The GPL works perfectly for the kernel.

But it doesn't mean the GPL works for everything, infact the GPL
translates to a sort of BSD behind the firewall.

Ask to Ingo the link to the kernel source running in the google
supercomputer if he keeps saying that the GPL works universally.

Ask to Ingo what was deadly wrong with the LGPL that made he decide
that it would have been bad if people writing LGPL code would have
been allowed to use his patent-pending ideas. (Then re-ask him the
same question after replacing the LGPL with the BSD license).

Re: [patch] let CONFIG_SECCOMP default to n

[Linus Torvalds]

On Wed, 12 Jul 2006, Andrew Morton wrote:
> 
> But looking at it, I think it's a bit confused.  The patch needs
> s/DISABLE_TSC/ENABLE_TSC/ to make it right.

No, SECCOMP_DISABLE_TSC _enables_ the "disable TSC" feature.

Rather confusing naming, I'd agree.

That said, I still think the code is crap, and that if we want to support 
tasks that don't have access to the TSC, we should make that an 
independent feature of anything like SECCOMP. 

		Linus

Re: [patch] let CONFIG_SECCOMP default to n

[Andrew Morton]

On Wed, 12 Jul 2006 23:07:32 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> Despite good resons to apply the patch, it has not been applied yet, 
> with no explanation.

I queued the below.  Andrea claims that it'll reduce seccomp overhead to
literally zero.

But looking at it, I think it's a bit confused.  The patch needs
s/DISABLE_TSC/ENABLE_TSC/ to make it right.





From: Andrea Arcangeli <andrea@cpushare.com>

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

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 arch/i386/Kconfig            |   12 ++++++++++++
 arch/i386/kernel/process.c   |    2 ++
 arch/x86_64/Kconfig          |   12 ++++++++++++
 arch/x86_64/kernel/process.c |   31 +++++++++++++++++++++++++++++++
 4 files changed, 57 insertions(+)

diff -puN arch/i386/Kconfig~add-seccomp_disable_tsc-config-option arch/i386/Kconfig
--- a/arch/i386/Kconfig~add-seccomp_disable_tsc-config-option
+++ a/arch/i386/Kconfig
@@ -737,6 +737,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.
+
 config VGA_NOPROBE
        bool "Don't probe VGA at boot" if EMBEDDED
        default n
diff -puN arch/i386/kernel/process.c~add-seccomp_disable_tsc-config-option arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c~add-seccomp_disable_tsc-config-option
+++ a/arch/i386/kernel/process.c
@@ -572,6 +572,7 @@ handle_io_bitmap(struct thread_struct *n
 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 -puN arch/x86_64/Kconfig~add-seccomp_disable_tsc-config-option arch/x86_64/Kconfig
--- a/arch/x86_64/Kconfig~add-seccomp_disable_tsc-config-option
+++ a/arch/x86_64/Kconfig
@@ -526,6 +526,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 -puN arch/x86_64/kernel/process.c~add-seccomp_disable_tsc-config-option arch/x86_64/kernel/process.c
--- a/arch/x86_64/kernel/process.c~add-seccomp_disable_tsc-config-option
+++ a/arch/x86_64/kernel/process.c
@@ -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)
@@ -622,6 +651,8 @@ __switch_to(struct task_struct *prev_p, 
 		}
 	}
 
+	disable_tsc(prev_p, next_p);
+
 	/* If the task has used fpu the last 5 timeslices, just do a full
 	 * restore of the math state immediately to avoid the trap; the
 	 * chances of needing FPU soon are obviously high now
_

Re: [patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

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

> 
> > > 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.
> 
> Hmm, with the new thread test as it was pointed out it can be indeed 
> made zero cost for the common case. Perhaps that's not needed then.

putting aside the fundamental fallacy of disabling TSC based timing 
attacks while not even considering network-based timing attacks (which 
are still very much possible), Chuck's approach of pushing the seccomp 
TSC cr4 twiddling into the context-switch slowpath is the right 
solution, given the circumstances. Will Chuck's patch be in 2.6.18? If 
not then my months-old patch below should be applied.

	Ingo

----

remove TSC-disabling logic from the context-switch hotpath. It has
marginal security relevance. Truly paranoid users can boot with the
TSC disabled anyway.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
----

 arch/i386/kernel/process.c |   29 -----------------------------
 1 files changed, 29 deletions(-)

Index: linux/arch/i386/kernel/process.c
===================================================================
--- linux.orig/arch/i386/kernel/process.c
+++ linux/arch/i386/kernel/process.c
@@ -589,33 +589,6 @@ handle_io_bitmap(struct thread_struct *n
 }
 
 /*
- * 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)
-{
-	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);
-	}
-}
-
-/*
  *	switch_to(x,yn) should switch tasks from x to y.
  *
  * We fsave/fwait so that an exception goes off at the right time
@@ -709,8 +682,6 @@ struct task_struct fastcall * __switch_t
 	if (unlikely(prev->io_bitmap_ptr || next->io_bitmap_ptr))
 		handle_io_bitmap(next, tss);
 
-	disable_tsc(prev_p, next_p);
-
 	return prev_p;
 }
 

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

> On Wed, 12 Jul 2006, Chuck Ebbert wrote:
> >
> > We can just fold the TSC disable stuff into the new thread_flags test
> > at context-switch time:

Great idea Chunk! We already use them in the syscall, it sounds a
perfect fit ;).

On Wed, Jul 12, 2006 at 02:55:38PM -0700, Linus Torvalds wrote:
> 
> I really think that this should be cleaned up to _not_ confuse the issue 
> of TSC with any "secure computing" issue.
> 
> The two have nothing to do with each other from a technical standpoint. 
> 
> Just make the flag be called "TIF_NOTSC", and then any random usage 
> (whether it be seccomp or anything else) can just set that flag, the same 
> way ioperm() sets TIF_IO_BITMAP.
> 
> Much cleaner. 
> 
> There's no point in mixing up an implementation detail like SECCOMP with a 
> feature like this.

The only single advantage I can see in remaining purely in function of
seccomp instead of going in function of _TIF_NOTSC, is that the below
block would be completely optimized away at compile time when
CONFIG_SECCOMP is set to N. This now become a slow-path, but then I'm
unsure if the anti-seccomp advocates can live with this block in the
slow path given that seccomp will be the only user of the feature. I
suspect they won't like it but then I could be wrong.

I like it either ways.

	/*
	 * Context switch may need to tweak the TSC disable bit in CR4.
	 * The optimizer should remove this code when !CONFIG_SECCOMP.
	 */
	if (has_secure_computing(task_thread_info(prev_p)) ^
	    has_secure_computing(task_thread_info(next_p))) {
		/* prev and next are different */
		if (has_secure_computing(task_thread_info(next_p)))
			write_cr4(read_cr4() | X86_CR4_TSD);
		else
			write_cr4(read_cr4() & ~X86_CR4_TSD);
	}

Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen]

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

Hmm, with the new thread test as it was pointed out it can be indeed made zero 
cost for the common case. Perhaps that's not needed then.

-Andi

Re: [patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

* 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

Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen]

On Wednesday 12 July 2006 23:22, Ingo Molnar wrote:

> 
> i think Andrea didnt even try to fix/generalize ptrace perhaps because 
> that would make his 'security feature' too banal? 

seccomp in its current state is already "banal". I think that was the
whole point of it. If he had wanted to do something complicated I'm sure
LSM would have offered lots of opportunity to go wild @). But seccomp
is really simple and easy to analyze. I bet if he could have made
it simpler he would have done that too.

That said the problems I see with using ptrace for this is that it
just adds too many context switches for each syscall and would be likely too slow.
Hmm, actually there might not be that many syscalls for these applications
(just some reads and writes) so it might work or not. But it would certainly be slower 
than it is right now. Would probably need some testing.

If utrace allows to do the filtering in kernel space it would 
be probably a useful replacement. I don't remember enough of the code
to know if it can do this or not. But I suppose it would still
need a kernel module or kernel patch of some sort to implement this
specific filtering.

> there's 
> nothing inherently insecure about the _client side_ of the ptrace APIs 
> or the client side of ptrace implementation. 

Agreed. 

> So my suggestion is to get  
> utrace in, to implement an utrace module that implements untrusted code 
> execution and then lets get rid of seccomp.

Sounds fine to me in theory (without having looked at any code) 

-Andi

Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen]

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

Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen]

> We can just fold the TSC disable stuff into the new thread_flags test
> at context-switch time:

I don't think it will work because you need to check state of 
both previous and next task. The thread_flags test only checks the
state of the next task.

-Andi

Re: [patch] let CONFIG_SECCOMP default to n

[Linus Torvalds]

On Wed, 12 Jul 2006, Chuck Ebbert wrote:
>
> We can just fold the TSC disable stuff into the new thread_flags test
> at context-switch time:

I really think that this should be cleaned up to _not_ confuse the issue 
of TSC with any "secure computing" issue.

The two have nothing to do with each other from a technical standpoint. 

Just make the flag be called "TIF_NOTSC", and then any random usage 
(whether it be seccomp or anything else) can just set that flag, the same 
way ioperm() sets TIF_IO_BITMAP.

Much cleaner. 

There's no point in mixing up an implementation detail like SECCOMP with a 
feature like this.

			Linus

Re: [patch] let CONFIG_SECCOMP default to n

[Chuck Ebbert]

In-Reply-To: <p73wtain80h.fsf@verdi.suse.de>

On 12 Jul 2006 17:43:42 +0200, Andi Kleen wrote:

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > 
> > I really don't care about cpushare and patents for some users of the
> > code in question. On the other hand turning on performance harming code
> > for a tiny number of users is dumb. If it were a loadable module it
> > would be different.
> 
> Actually there are some promising applications of seccomp outside
> cpushare.
> 
> e.g. Andrea at some point proposed to run codecs which often
> have security issues in a simple cpusec jail.  That's ok for 
> them because they normally don't need to do any system calls.
> 
> I liked the idea. While this can be done with LSM (e.g. apparmor) too 
> seccomp is definitely much easier and simpler and more "obviously safe"
> than anything LSM based.
> 
> 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.

We can just fold the TSC disable stuff into the new thread_flags test
at context-switch time:

[compile tested only; requires just-sent fix to i386 system.h]

 arch/i386/kernel/process.c     |   61 ++++++++++++++---------------------------
 include/asm-i386/thread_info.h |    3 +-
 2 files changed, 24 insertions(+), 40 deletions(-)

--- 2.6.18-rc1-nb.orig/arch/i386/kernel/process.c
+++ 2.6.18-rc1-nb/arch/i386/kernel/process.c
@@ -535,12 +535,11 @@ int dump_task_regs(struct task_struct *t
 	return 1;
 }
 
-static noinline void __switch_to_xtra(struct task_struct *next_p,
-				    struct tss_struct *tss)
+static noinline void
+__switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
+		 struct tss_struct *tss)
 {
-	struct thread_struct *next;
-
-	next = &next_p->thread;
+	struct thread_struct *next = &next_p->thread;
 
 	if (test_tsk_thread_flag(next_p, TIF_DEBUG)) {
 		set_debugreg(next->debugreg[0], 0);
@@ -552,6 +551,19 @@ static noinline void __switch_to_xtra(st
 		set_debugreg(next->debugreg[7], 7);
 	}
 
+	/*
+	 * Context switch may need to tweak the TSC disable bit in CR4.
+	 * The optimizer should remove this code when !CONFIG_SECCOMP.
+	 */
+	if (has_secure_computing(task_thread_info(prev_p)) ^
+	    has_secure_computing(task_thread_info(next_p))) {
+		/* prev and next are different */
+		if (has_secure_computing(task_thread_info(next_p)))
+			write_cr4(read_cr4() | X86_CR4_TSD);
+		else
+			write_cr4(read_cr4() & ~X86_CR4_TSD);
+	}
+
 	if (!test_tsk_thread_flag(next_p, TIF_IO_BITMAP)) {
 		/*
 		 * Disable the bitmap via an invalid offset. We still cache
@@ -561,7 +573,7 @@ static noinline void __switch_to_xtra(st
 		return;
 	}
 
-	if (likely(next == tss->io_bitmap_owner)) {
+	if (likely(tss->io_bitmap_owner == next)) {
 		/*
 		 * Previous owner of the bitmap (hence the bitmap content)
 		 * matches the next task, we dont have to do anything but
@@ -583,33 +595,6 @@ static noinline void __switch_to_xtra(st
 }
 
 /*
- * 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)
-{
-	struct thread_info *prev, *next;
-
-	/*
-	 * gcc should eliminate the ->thread_info dereference if
-	 * has_secure_computing returns 0 at compile time (SECCOMP=n).
-	 */
-	prev = task_thread_info(prev_p);
-	next = task_thread_info(next_p);
-
-	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);
-	}
-}
-
-/*
  *	switch_to(x,yn) should switch tasks from x to y.
  *
  * We fsave/fwait so that an exception goes off at the right time
@@ -688,13 +673,11 @@ struct task_struct fastcall * __switch_t
 		set_iopl_mask(next->iopl);
 
 	/*
-	 * Now maybe handle debug registers and/or IO bitmaps
+	 * Now maybe handle debug registers, IO bitmaps, TSC disable
 	 */
-	if (unlikely((task_thread_info(next_p)->flags & _TIF_WORK_CTXSW))
-	    || test_tsk_thread_flag(prev_p, TIF_IO_BITMAP))
-		__switch_to_xtra(next_p, tss);
-
-	disable_tsc(prev_p, next_p);
+	if (unlikely(task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV ||
+		     task_thread_info(next_p)->flags & _TIF_WORK_CTXSW_NEXT))
+		__switch_to_xtra(prev_p, next_p, tss);
 
 	return prev_p;
 }
--- 2.6.18-rc1-nb.orig/include/asm-i386/thread_info.h
+++ 2.6.18-rc1-nb/include/asm-i386/thread_info.h
@@ -164,7 +164,8 @@ static inline struct thread_info *curren
 #define _TIF_ALLWORK_MASK	(0x0000FFFF & ~_TIF_SECCOMP)
 
 /* flags to check in __switch_to() */
-#define _TIF_WORK_CTXSW (_TIF_DEBUG|_TIF_IO_BITMAP)
+#define _TIF_WORK_CTXSW_NEXT (_TIF_IO_BITMAP | _TIF_SECCOMP | _TIF_DEBUG)
+#define _TIF_WORK_CTXSW_PREV (_TIF_IO_BITMAP | _TIF_SECCOMP)
 
 /*
  * Thread-synchronous status.
-- 
Chuck
 "You can't read a newspaper if you can't read."  --George W. Bush

Re: [patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

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

> I liked the idea. While this can be done with LSM (e.g. apparmor) too 
> seccomp is definitely much easier and simpler and more "obviously 
> safe" than anything LSM based.

LSM is probably too heavy for this - but utrace (posted by Roland 
McGrath a few weeks ago) is alot more focused on modularizing ptrace 
features. utrace also solves a whole host of other issues that we have 
with ptrace!

for example the first sample utrace module that Roland posted was a 
'stop the task if it becomes undebugged, instead of letting the task run 
away'. That solves precisely the ptrace property that Andrea complained 
about most.

i think Andrea didnt even try to fix/generalize ptrace perhaps because 
that would make his 'security feature' too banal? It would also become 
unpatentable? Even though this decision hurts the 'reach' of his project 
fundamentally: ptrace support is everywhere, and users could very much 
and consciously decide to run 'compatible ptrace' or 'more secure 
ptrace' [provided by newer kernels].

Andrea's "ptrace is insecure" argument is just plain FUD: there's 
nothing inherently insecure about the _client side_ of the ptrace APIs 
or the client side of ptrace implementation. So my suggestion is to get 
utrace in, to implement an utrace module that implements untrusted code 
execution and then lets get rid of seccomp.

	Ingo

Re: [patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

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

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 <mingo@elte.hu>
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 <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

Re: [patch] let CONFIG_SECCOMP default to n

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> I really don't care about cpushare and patents for some users of the
> code in question. On the other hand turning on performance harming code
> for a tiny number of users is dumb. If it were a loadable module it
> would be different.

Actually there are some promising applications of seccomp outside
cpushare.

e.g. Andrea at some point proposed to run codecs which often
have security issues in a simple cpusec jail.  That's ok for 
them because they normally don't need to do any system calls.

I liked the idea. While this can be done with LSM (e.g. apparmor) too 
seccomp is definitely much easier and simpler and more "obviously safe"
than anything LSM based.

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.

-Andi

Re: [patch] let CONFIG_SECCOMP default to n

[Alan Cox]

Ar Maw, 2006-07-11 am 18:13 +0200, ysgrifennodd andrea@cpushare.com:
> On Tue, Jul 11, 2006 at 05:54:02PM +0200, Arjan van de Ven wrote:
> Aren't Ingo and Alan Fedora? If they ask N in the main kernel, and they
> already set it to N in fedora I'm unsure what I should discuss further
> with them.

Neither of us are the ones who set the final options for Fedora kernels,
although I'd be suprised given the minisclue user base and the added
cost to every user if anyone else reached a differing conclusion, but
that is for the Fedora Project to decide not for me.

Re: [patch] let CONFIG_SECCOMP default to n

[Alan Cox]

Ar Maw, 2006-07-11 am 17:54 +0200, ysgrifennodd Arjan van de Ven:
> On Tue, 2006-07-11 at 17:31 +0200, andrea@cpushare.com wrote:
> Fedora is done by the Fedora project, not by Red Hat the company. If you
> want to ask them to enable it, you should do so on the fedora-devel
> mailing list

Or roll your own alternative kernel package and set up a mini yum
repository for it and updates you make. The GPL is a wonderful thing 8)

Re: [patch] let CONFIG_SECCOMP default to n

[Alan Cox]

Ar Maw, 2006-07-11 am 17:31 +0200, ysgrifennodd andrea@cpushare.com:
> If they don't reconsider I'll be forced to recommend the Fedora CPUShare
> users to switch distro if they don't want having to recompile the kernel
> by themself.

I'm sure they'll both be deeply upset.

I really don't care about cpushare and patents for some users of the
code in question. On the other hand turning on performance harming code
for a tiny number of users is dumb. If it were a loadable module it
would be different.


Alan

Re: [patch] let CONFIG_SECCOMP default to n

[Arjan van de Ven]

On Tue, 2006-07-11 at 18:13 +0200, andrea@cpushare.com wrote:
> On Tue, Jul 11, 2006 at 05:54:02PM +0200, Arjan van de Ven wrote:
> > Ehm I wasn't aware all linux vendors in the world owe that to you, or
> > that you own their kernel configuration
> 
> I perfectly know nobody owes anything to me, I said I didn't expect it
> because it sounds very weird having to take an anti-fedora position in a
> project like CPUShare. 

it sounds very weird taking an anti-fedora position without even having
asked Fedora to turn it on. But maybe that's just me.

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

On Tue, Jul 11, 2006 at 06:02:36PM +0200, Adrian Bunk wrote:
> And it was you who said just a few days ago [1]:
> 
> <--  snip  -->
> 
> ...
> 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 ;).
> 
> <--  snip  -->

The above was in the context of the mainline kernel in case you didn't
notice (when I wrote the above I expected fedora to set it to Y even if
the main kernel was set to N, imagine how way off I was when I wrote the
above ;).

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

On Tue, Jul 11, 2006 at 05:54:02PM +0200, Arjan van de Ven wrote:
> Ehm I wasn't aware all linux vendors in the world owe that to you, or
> that you own their kernel configuration

I perfectly know nobody owes anything to me, I said I didn't expect it
because it sounds very weird having to take an anti-fedora position in a
project like CPUShare. Hope you didn't get it wrong because I'd be sad
having opened this whole topic if you were wrong and SECCOMP was
actually enabled in fedora.

> I have no idea; I don't work there. Also I checked Fedora, not RHEL, and
> Fedora is done by the Fedora project, not by Red Hat the company. If you
> want to ask them to enable it, you should do so on the fedora-devel
> mailing list

Aren't Ingo and Alan Fedora? If they ask N in the main kernel, and they
already set it to N in fedora I'm unsure what I should discuss further
with them.

And most of this whole thread is grossly offtopic, I'm amazed nobody
complained yet about the questions they ask about cpushare legal details
on this list, I guess it was entertaining enough for people not to
complain just yet.

I won't post more emails from my part... hope it helps reducing the
noise.

Re: [patch] let CONFIG_SECCOMP default to n

[Adrian Bunk]

On Tue, Jul 11, 2006 at 05:31:17PM +0200, andrea@cpushare.com wrote:
> On Tue, Jul 11, 2006 at 04:32:53PM +0200, Arjan van de Ven wrote:
>...
> > if there is overhead, and there is no general use for it (which there
> > isn't really) then it should be off imo.
> 
> I hope the reason was the lack of my last patch. But even in such case
> RH could have turned off the tsc thing immediately themself (they know
> how to patch the kernel no?) or they could have asked me a single
> question about it before turning it off, no?
> 
> I hope RH will reconsider with my last patch applied and at the light of
> this email as well:
> 
> 	http://www.cpushare.com/hypermail/cpushare-discuss/06/01/0080.html
> 
> If they don't reconsider I'll be forced to recommend the Fedora CPUShare
> users to switch distro if they don't want having to recompile the kernel
> by themself.
> 
> I guess now I understand why this new change of mind of Ingo: if he
> would succeed to push the N in the main kernel, then nobody could
> complain to fedora for setting it to N, while they're in a less obvious
> position at the moment where the kernel says "default to y" and they set
> it to N to be happy.
>...

WTF are you smoking?

You said yourself that your feature has currently exactly 121 users.

And why should anyone have to contact you before disabling your feature?
Everyone enables the subset of features he considers useful, and there's
no reason to contact anyone when disabling a feature in the kernel
(or would you consider it a morally bad thing that I disabled kernel 
preemption in my kernel without asking anyone for permission?).

And it was you who said just a few days ago [1]:

<--  snip  -->

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

<--  snip  -->

cu
Adrian

[1] http://lkml.org/lkml/2006/6/30/132

-- 

       "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: [patch] let CONFIG_SECCOMP default to n

[Pavel Machek]

Hi!

> > > > 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. [...]
> > 
> > so you admit and confirm that you explicitly and intentionally do not 
> > pledge your patent to GPL users. [..]
> 
> How many times do I need to say it. The pending patent has nothing to do
> with the kernel, and it is _not_ pledged under the GPL.
...
> Talking about patents when submitting seccomp, would be like talking
> about mp3 patents when submitting alsa code or talking about google

Well, if mp3 was only known user of alsa, yes that would be relevant
discussion... and that seems to be the case here.
							Pavel
-- 
Thanks for all the (sleeping) penguins.

Re: [patch] let CONFIG_SECCOMP default to n

[Arjan van de Ven]

On Tue, 2006-07-11 at 17:31 +0200, andrea@cpushare.com wrote:
> On Tue, Jul 11, 2006 at 04:32:53PM +0200, Arjan van de Ven wrote:
> > as far as I can see Fedora has SECCOMP off for a long time already
> 
> Well, I didn't know about it... Long time can't be more than a few
> months because I was sure in older releases it was enabled because I had
> people running seccomp code on fedora.

hmm I checked my laptop which runs a quite old version

> I never expect it was easy thing to startup the CPUShare project, but
> one thing that I didn't expect however was this kind of behaviour from
> the leading linux vendor, I didn't get a single email of questions and I
> wasn't informed about this, despite they know me perfectly. 

Ehm I wasn't aware all linux vendors in the world owe that to you, or
that you own their kernel configuration

> > if there is overhead, and there is no general use for it (which there
> > isn't really) then it should be off imo.
> 
> I hope the reason was the lack of my last patch. But even in such case
> RH could have turned off the tsc thing immediately themself (they know
> how to patch the kernel no?) or they could have asked me a single
> question about it before turning it off, no?
> 

I have no idea; I don't work there. Also I checked Fedora, not RHEL, and
Fedora is done by the Fedora project, not by Red Hat the company. If you
want to ask them to enable it, you should do so on the fedora-devel
mailing list

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

On Tue, Jul 11, 2006 at 04:32:53PM +0200, Arjan van de Ven wrote:
> as far as I can see Fedora has SECCOMP off for a long time already

Well, I didn't know about it... Long time can't be more than a few
months because I was sure in older releases it was enabled because I had
people running seccomp code on fedora.

I never expect it was easy thing to startup the CPUShare project, but
one thing that I didn't expect however was this kind of behaviour from
the leading linux vendor, I didn't get a single email of questions and I
wasn't informed about this, despite they know me perfectly. This
effectively reminds me about the high profile news articles I keep
reading recently that on the sidelines mentions about some RH behaviour
in the industry.

> if there is overhead, and there is no general use for it (which there
> isn't really) then it should be off imo.

I hope the reason was the lack of my last patch. But even in such case
RH could have turned off the tsc thing immediately themself (they know
how to patch the kernel no?) or they could have asked me a single
question about it before turning it off, no?

I hope RH will reconsider with my last patch applied and at the light of
this email as well:

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

If they don't reconsider I'll be forced to recommend the Fedora CPUShare
users to switch distro if they don't want having to recompile the kernel
by themself.

I guess now I understand why this new change of mind of Ingo: if he
would succeed to push the N in the main kernel, then nobody could
complain to fedora for setting it to N, while they're in a less obvious
position at the moment where the kernel says "default to y" and they set
it to N to be happy.

As for no general use, this is the people that certainly used seccomp so
far:

cpushare=> select count(*) from accounts where cpucoins != 0;
 count 
-------
   122
(1 row)

cpushare=> 

remove 1 that is myself, that leaves 121 persons using seccomp so far
in CPUShare context. One first user already started buying CPU resource
a few days ago, and he's currently computing his own seccomp bytecode
remotely as we speak. So unless they're all wasting their time by
helping me testing the stuff, I'm not the only one that find at least
one useful usage for seccomp (but I think there are many more if only
people would care to use it). Certainly the FUD about the Y and N
availability doesn't help in convincing people to use seccomp to
strengthen decompression security etc...

Re: [patch] let CONFIG_SECCOMP default to n

[Arjan van de Ven]

> Note that I don't think Y or N makes any difference at the end for my
> project. But fedora could set it to N under your advice and that would
> do more damage to my project than whatever default setting we have

as far as I can see Fedora has SECCOMP off for a long time already

> Even if you seem to believe I don't care about the kernel when I talk
> about seccomp, I really think Y is the right setting for the kernel, and
> I'm not speaking for my own personal usages of seccomp, for the reason
> why you also agreed with it in the above email a few months ago.

if there is overhead, and there is no general use for it (which there
isn't really) then it should be off imo.

Re: [patch] let CONFIG_SECCOMP default to n

[andrea]

On Tue, Jul 11, 2006 at 09:36:25AM +0200, Ingo Molnar wrote:
> 
> * andrea@cpushare.com <andrea@cpushare.com> wrote:
> 
> > 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. [...]
> 
> so you admit and confirm that you explicitly and intentionally do not 
> pledge your patent to GPL users. [..]

How many times do I need to say it. The pending patent has nothing to do
with the kernel, and it is _not_ pledged under the GPL.

The software world is moving from proprietary software that runs on top
of end user computers, to proprietary software that runs behind the
firewall. And the GPL is getting old and not capable to cope with the
second kind of usage of the software. This is being discussed in gplv3
context.

This isn't too bad, because as long as the software you run is open
source, you're guaranteed to be in control of what runs on your
computer, in control of your privacy, and in control of your security.
So it's a better model, you pratically run the proprietary software on
the server through the firefox open source client stack, but but the
general forced-contribution-mode that the GPL allows, tends to weaken
signficantly when software is only meant to run behind the firewall of
large corporations that don't depend on external companies for their own
software support.

I've no magic solution for this, I'm not a lawyer so I've no idea if
anything more than the GPL would be enforceable under US law in the
first place (until recently it wasn't even 100% sure that the GPL was
enforceable), so I certainly can't help on this side.

> [..] That is troubling (and unethical) in my 

You should talk about ethics to the people that written the law,
certainly not with me. I've to comply with the law and with the rules of
economy. It's not my fault the fact that if I don't file patents I risk
troubles ahead. I'm against patents too and it wasn't fun to pay for the
legal costs of the filing. I seem to recall that transmeta also filed a
software patent over the CMS but it seems people had not many problems
to work for them (you once sent emails @transmeta.com too). Transmeta
perhaps was the smallest player, there are many more bigger examples
that I won't be making.

Furthermore I obtained no patents yet, it could be the way I written the
text is wrong or whatever, I'm not the most expert in terms of patents,
I did my best just to be sure I couldn't regret having done a fatal
and obvious mistake later and it seems everything is going fine, but
doing my best is definitely no guarantee of success. So it could be all
this will be void if I've bad luck and they reject my application.

> opinion and strengthens my argument that this feature should be _at a 
> minimum_ be made default-off, just like hundreds of other kernel 
> features are.

See the below email of yours.

Also note, seccomp is the basic mode, at some point trusted
computing will be supported by xen so then I'll have a compelling reason
to switch the client side from seccomp to xen. But even then I'll be
always supporting seccomp for a long time because it's the most solid
and simplest mode of all.

> I'm also wondering what the upstream decision would have been, had you 
> disclosed this patent licensing intention of yours. (to use the GPL-ed 

Talking about patents when submitting seccomp, would be like talking
about mp3 patents when submitting alsa code or talking about google
server side patents when submitting a new tcp/ip feature that could
allow google render html faster. This whole discussion is officially
offtopic and it's a pure waste of bandwidth(tm), believe it or not.

All grid computing providers out there are welcome to start using
seccomp today to make their clients more secure against possible
software bugs in the remote computed bytecode. I welcome boinc to start
using seccomp too, I welcome worldcommunitygrid to use seccomp on the
linux client, I welcome all OS vendors to add seccomp to their OS, I
even tried to contact apple since it should be easy to port seccomp to
their kernels.

As far as cpushare is concerned, I never had anything to hide. The legal
part of the website is there since day zero I think.

> Linux kernel as a vehicle for your 'invention', while not fully living 
> up to the basic quid-pro-quo.).

If you prefer I can move all patent pending code on top of windows,
though I believe the "powered by" ads on my site were nice ads for free
software and open source (and obviously I'm very proud to be using them
like I'm very proud to be able to contribute to free software as well).
If you check the user agreement I even stated that any income generated
by cpucoins transactions started by cpushare will be donated to the
development of open source software.

> So i'd like to request the patch below to be included in v2.6.18.

Here the email that now you're forcing me to remind you:

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

	"ok, i agree with you here - having it on by default does make
	sense from an API uniformity POV."

I didn't feel the need of mentioning this opinion of yours before as
backing for my arguments pro Y, because I thought you were agreeing with
my previous post and that my arguments alone were enough, but since you
changed your mind again...

Note that I don't think Y or N makes any difference at the end for my
project. But fedora could set it to N under your advice and that would
do more damage to my project than whatever default setting we have
in-kernel. So if you want to hurt my project, you should ask Dave to
turn off seccomp instead of asking Linus to turn off it in the kernel
source.

Even more significant is that fact that it turns out 90% of the
interested userbase seems windows based, so for 90% of users it won't
matter if seccomp is even in the kernel.

Even if you seem to believe I don't care about the kernel when I talk
about seccomp, I really think Y is the right setting for the kernel, and
I'm not speaking for my own personal usages of seccomp, for the reason
why you also agreed with it in the above email a few months ago.

But like I said in previous emails, if these discussion about Y or N
have to keep going, then feel free to apply Ingo patch to make him
happy. I'm happy either ways even but I think Y is the appropriate
setting like with EPOLL and friends, now that all overhead triggered by
the purely paranoid additional feature has been removed by default.

config EPOLL
        bool "Enable eventpoll support" if EMBEDDED
        default y

[patch] let CONFIG_SECCOMP default to n

[Ingo Molnar]

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

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

so you admit and confirm that you explicitly and intentionally do not 
pledge your patent to GPL users. That is troubling (and unethical) in my 
opinion and strengthens my argument that this feature should be _at a 
minimum_ be made default-off, just like hundreds of other kernel 
features are.

I'm also wondering what the upstream decision would have been, had you 
disclosed this patent licensing intention of yours. (to use the GPL-ed 
Linux kernel as a vehicle for your 'invention', while not fully living 
up to the basic quid-pro-quo.).

and i'm not really interested in marketing arguments about cpushare and 
seccomp in general. What matters to me is that this feature has been in 
the kernel for more than a year already, that nobody but you is using it 
and that _everyone_ using the default kernel options is paying the price 
in the context-switch hotpath. (The fact that in my view one of 
seccomp's obvious user-space usages is also patent-tainted without a 
fair pledge is 'just' icing on the cake.)

So i'd like to request the patch below to be included in v2.6.18.

	Ingo

---------------->
From: Ingo Molnar <mingo@elte.hu>
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 <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

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