On Wed, Nov 17, 2021 at 3:24 PM Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Nov 17, 2021 at 1:54 PM Kees Cook keescook@chromium.org wrote:
The SA_IMMUTABLE change was to deal with failures seen in the seccomp test suite after the recent fatal signal refactoring. Mainly that a process that should have effectively performed do_exit() was suddenly visible to the tracer.
I think this basically shows that the conversion from do_exit() to fatal_signal() was just wrong. The "do_exit()" wasn't really a signal, and can't be treated as such.
That said, instead of reverting, maybe we can just mark the cases where it really is about sending a synchronous signal, vs sending an explicitly fatal signal.
It's basically the "true" condition to force_sig_info_to_task(), so the fix might be just
@@ -1323,7 +1323,8 @@ force_sig_info_to_task(struct kernel_siginfo *info, struct task_struct *t, bool blocked = sigismember(&t->blocked, sig); if (blocked || ignored || sigdfl) { action->sa.sa_handler = SIG_DFL;
action->sa.sa_flags |= SA_IMMUTABLE;
if (sigdfl)action->sa.sa_flags |= SA_IMMUTABLE; if (blocked) { sigdelset(&t->blocked, sig); recalc_sigpending_and_wake(t);Kyle, does that fix your test-case? And Kees - yours?
This fixes most of the issues with rr, but it still changes the ptrace behavior for the double-SIGSEGV case (yes, we have a test for that too). The second SIGSEGV isn't reported to the ptracer and the program just skips straight to the PTRACE_EVENT_EXIT. This is visible in gdb as well (only the first SIGSEGV is caught).
- Kyle