Added support for sigreturn() and rt_sigreturn(). On x86-32, this is...

Added support for sigreturn() and rt_sigreturn(). On x86-32, this is
complicated by the fact that in Seccomp mode, we can only ever call
sigreturn(). But in order to eventually support sigaction(), we want to
be able to also call rt_sigreturn().

We solve this problem by rewriting the signal stack frame from an RT
signal frame to a legacy frame. Fortunately, this part of the signal
frame is stable between kernel versions. The unstable part (i.e. extended
registers such as FP, MMX, SSE, ...) is always identical in both in both
types of signal frames.

None of these complications exist on x86-64 and it is relatively
straight-forward to enable support for the system call. The only
difficulty lies in the fact that its calling conventions are somewhat
different from "normal" system calls. So, we have to handle rt_sigreturn()
from within the syscallWrapper() and the segv() handler and cannot write
it in C code.

TEST=ad hoc testing until we have support for sigaction(). Then we can add a unittest
BUG=37728
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=45774

[Markus (顧孟勤), 2010-04-27 02:13:45]

More crazy code. Sorry about that :-/

I know why I was so resistant to add support for signal handlers to the seccomp
sandbox. Fortunately, I can see light at the end of the tunnel. Sigaction() will
need one more hairy changelist, but then everything should be in place.

[agl, 2010-04-27 15:27:34]

LGTM

http://codereview.chromium.org/1739011/diff/1/4
File sandbox/linux/seccomp/sandbox.cc (right):

http://codereview.chromium.org/1739011/diff/1/4#newcode248
sandbox/linux/seccomp/sandbox.cc:248: "mov  $1, %%edi\n"           //
rt_sigreturn() should never return
Maybe a more magic number here? One is a bit common :)

http://codereview.chromium.org/1739011/diff/1/4#newcode325
sandbox/linux/seccomp/sandbox.cc:325: "cmpw $0x010F, (%%ebp)\n"    // RDTSC
Shouldn't the comment be "RDTSCP"?

http://codereview.chromium.org/1739011/diff/1/4#newcode333
sandbox/linux/seccomp/sandbox.cc:333: "mov  $0x16, %%ecx\n"
I would tend to write this as $22 rather than use hex. The 16 and the 0x cause a
mental hiccup.

http://codereview.chromium.org/1739011/diff/1/4#newcode338
sandbox/linux/seccomp/sandbox.cc:338: "lea  6f, %%esi\n"
I must admit that I'm not sure what's going on here. "6f"? You're copying from
the label 6: (below) into the structure?

http://codereview.chromium.org/1739011/diff/1/6
File sandbox/linux/seccomp/syscall.cc (right):

http://codereview.chromium.org/1739011/diff/1/6#newcode54
sandbox/linux/seccomp/syscall.cc:54: "mov  $1, %edi\n"              //
rt_sigreturn() should never return
Again, maybe more magic in the number?

http://codereview.chromium.org/1739011/diff/1/6#newcode147
sandbox/linux/seccomp/syscall.cc:147: "mov  $1, %ebx\n"              //
sigreturn() should never return
ditto