Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous.

On Mon, Feb 27, 2012 at 6:32 AM, Indan Zupancic [off-list ref] wrote:

On Thu, February 23, 2012 23:33, Markus Gutschke wrote:

quoted

On Thu, Feb 23, 2012 at 14:15, Indan Zupancic [off-list ref] wrote:

quoted

What about making SECCOMP_RET_TRAP dump core/send SIGSYS if there is
no tracer with PTRACE_O_SECCOMP set?

Please don't make things dependent on having a tracer. There are
applications that don't really need a tracer; in fact, these are
typically the exact same applications that can benefit from receiving
SIGSYS and then handling it internally.

My proposal was to send the SIGSYS only when there is no seccomp aware
tracer. If there is no such tracer, the process will receive a SIGSYS
that it can handle internally. So having a tracer isn't required.

I'm curious how you would like to handle SIGSYSs internally, because I
don't see how you could gracefully recover from such failed system call,
so I don't really see the added value compared to fail the syscall with
some ERRNO or to just kill the task. Is it just for notification purposes?

Take a look at samples/seccomp/bpf-direct.c.  You can emulate the call
which can be useful for patching up external code.   This is
especially useful if you don't want to hand patch every library that
is doing something you don't like without a full supervisor framework
(e.g., glibc checking for an nscd.socket file).

Another use is implementing a signal-handler based system call
delegation system.  E.g., setup your fds with a broker, then pass the
requested syscall number and desired arguments over to the broker from
the hanlder who can pass back an fd or whatever is appropriate.  Then
the return from the syscall can be fixed up.

quoted

If a tracer was required to set this up, it would make it difficult to
use gdb, strace, or any other common debugging tools.

gdb and strace and such won't set the PTRACE_O_SECCOMP option, so it
will behave the same whether it's being debugged or not.

The main objective was to reduce the amount of policy in filters,
I thought it could be done by having only one return value which
delegates to user space. But that may be too confusing, and the
interaction between a seccomp aware tracer and SIGSYS aware code
is fuzzy, so I'm not sure if it's a good idea.

Yeah - I want to avoid as much implicit behavior as possible.  It's a
trap I regularly fall in and both you and luto@ have kept me honest
this time. I don't want to regress :)

quoted

quoted

Sending SIGSYS is useful, but it's quite a bit less useful if user
space can't handle it in a signal handler, so I don't think it's
worth it to make a unblockable version.

Maybe, I am not parsing your e-mail correctly. But don't we already
get the desired behavior, if SIGSYS is treated the same as any other
synchronous signal? If it is unblocked and has a handler, the
application can decide to handle it. If neither one of these
conditions is true, it terminates the program. Ulimits and
PR_SET_DUMPABLE determine whether a core file is generated.

The proposal I was replying to wanted to make SIGSYS always kill the
process (with a core dump), so you wouldn't be able to set a handler
any more. I think that is a bad idea. Or did I misunderstood?

Yeah - I suspect some crossed wires.  The idea of a forced core dump
seems useful in some scenarios, but it is not hard to synthesize with
the RET_TRAP already.  If something like RET_CORE is more obviously
useful after we have all the proposed consumers using this interface,
then it would make sense to entertain it then.

Enforcing task termination when there is no handler doesn't make
conceptual sense, because an empty signal handler is effectively
the same as blocking a signal. Though I guess it's simpler to check
for just sigaction in the BPF filters, so perhaps that was the idea.

Pretty much, I guess.  Right now RET_TRAP calls force_siginfo which
will either use an installed handler or unblock the signal and use
SIG_DFL, which is just dump core.  So the tweak would be to just set
it back to SIG_DFL prior to delivery (like force_sigsegv does when it
detects it is double-faulting).

Anyway, I think that forcing a coredump with a return code is overkill
at this point.  do_exit(SIGSYS) is nice and so is using RET_TRAP to
trigger a core.  Whether RET_TRACE should emit a sigsys when a tracer
isn't present is less clear to me, but I think keeping behavior
explicit will end up leading to the least number of mistakes and
breaks.

Thanks!
will