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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <202111171049.3F9C5F1@keescook> Date: Wed, 17 Nov 2021 10:51:30 -0800 From: Kees Cook <keescook@...omium.org> To: Kyle Huey <me@...ehuey.com> Cc: "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@...r.kernel.org, open list <linux-kernel@...r.kernel.org>, linux-hardening@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, Robert O'Callahan <rocallahan@...il.com> Subject: Re: [REGRESSION] 5.16rc1: SA_IMMUTABLE breaks debuggers On Wed, Nov 17, 2021 at 10:47:13AM -0800, Kyle Huey wrote: > rr, a userspace record and replay debugger[0], is completely broken on > 5.16rc1. I bisected this to 00b06da29cf9dc633cdba87acd3f57f4df3fd5c7. > > That patch makes two changes, it blocks sigaction from changing signal > handlers once the kernel has decided to force the program to take a > signal and it also stops notifying ptracers of the signal in the same > circumstances. The latter behavior is just wrong. There's no reason > that ptrace should not be able to observe and even change > (non-SIGKILL) forced signals. It should be reverted. > > This behavior change is also observable in gdb. If you take a program > that sets SIGSYS to SIG_IGN and then raises a SIGSYS via > SECCOMP_RET_TRAP and run it under gdb on a good kernel gdb will stop > when the SIGSYS is raised, let you inspect program state, etc. After > the SA_IMMUTABLE change gdb won't stop until the program has already > died of SIGSYS. Ah, hm, this was trying to fix the case where a program trips SECCOMP_RET_KILL (which is a "fatal SIGSYS"), and had been unobservable before. I guess the fix was too broad... -- Kees Cook
Powered by blists - more mailing lists