[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP045AoMY4xf8aC_4QU_-j7obuEPYgTcnQQP3Yxk=2X90jtpjw@mail.gmail.com>
Date: Wed, 17 Nov 2021 10:47:13 -0800
From: Kyle Huey <me@...ehuey.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Andrea Righi <andrea.righi@...onical.com>,
Kees Cook <keescook@...omium.org>,
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: [REGRESSION] 5.16rc1: SA_IMMUTABLE breaks debuggers
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.
- Kyle
[0] https://rr-project.org/
Powered by blists - more mailing lists