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: Thu, 10 Feb 2022 18:53:42 -0800 From: Kees Cook <keescook@...omium.org> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Robert Święcki <robert@...ecki.net>, Andy Lutomirski <luto@...capital.net>, Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org Subject: Re: [PATCH 0/3] signal: HANDLER_EXIT should clear SIGNAL_UNKILLABLE On Thu, Feb 10, 2022 at 07:47:00PM -0600, Eric W. Biederman wrote: > Kees Cook <keescook@...omium.org> writes: > > The common accessors for the bits are set_syscall_work()/clear_syscall_work() > > but I don't see anything to operate on an entire mask. Maybe it needs to > > grow something like reset_syscall_work()? > > Oh. I hadn't realized SYSCALL_WORK_EXIT and TIF_SYSCALL_WORK were > masks. Yes it looks like a simple addition of reset_syscall_work() > and calling it from force_sig_info when HANDLER_EXIT will hide these > events. Yeah, it's varied by features, architectures, etc. The good news is it's WAY nicer now after the USER_DISPATCH. :) > When you say the events are corrupted did you mean they return wrong data > to userspace or simply that the events should not fire? It's mainly about the exit stuff having never been run before on these kinds of process states, so things don't make sense. For example, on the SIGSYS death, the registers have been rewound for the coredump, so when the exit trace runs on x86 it sees the syscall return value as equal to the syscall number (since %rax is used for the syscall number on entry and for the syscall result on exit). So when a tracer watches a seccomp fatal SIGSYS, it sees the syscall exit before it sees the child exit (and therefore the signal). For example, x86_64 write (syscall number 1), will return as if it had written 1 byte. :P So, it's not harmful, but it's confusing and weird. :) > I am trying to figure out if there is a case to be made that it was a > bug that these events were missing. I don't think so -- the syscall did not finish, so there isn't a valid return code. The process exited before it completed. -- Kees Cook
Powered by blists - more mailing lists