lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 17 Nov 2021 16:37:21 -0800 From: Kyle Huey <me@...ehuey.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Kees Cook <keescook@...omium.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Andrea Righi <andrea.righi@...onical.com>, Shuah Khan <shuah@...nel.org>, Alexei Starovoitov <ast@...nel.org>, Andy Lutomirski <luto@...capital.net>, Will Drewry <wad@...omium.org>, "open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, bpf <bpf@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, linux-hardening@...r.kernel.org, "Robert O'Callahan" <rocallahan@...il.com> Subject: Re: [REGRESSION] 5.16rc1: SA_IMMUTABLE breaks debuggers On Wed, Nov 17, 2021 at 3:24 PM Linus Torvalds <torvalds@...ux-foundation.org> wrote: > > On Wed, Nov 17, 2021 at 1:54 PM Kees Cook <keescook@...omium.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
Powered by blists - more mailing lists