Messages in this thread |  | | Date | Mon, 25 Oct 2021 15:32:52 -0700 | Subject | Re: [PATCH 14/20] exit/syscall_user_dispatch: Send ordinary signals on failure | From | Andy Lutomirski <> |
| |
On 10/21/21 09:25, Kees Cook wrote: > On Wed, Oct 20, 2021 at 12:44:00PM -0500, Eric W. Biederman wrote: >> Use force_fatal_sig instead of calling do_exit directly. This ensures >> the ordinary signal handling path gets invoked, core dumps as >> appropriate get created, and for multi-threaded processes all of the >> threads are terminated not just a single thread. >> >> When asked Gabriel Krisman Bertazi <krisman@collabora.com> said [1]: >>> ebiederm@xmission.com (Eric W. Biederman) asked: >>> >>>> Why does do_syscal_user_dispatch call do_exit(SIGSEGV) and >>>> do_exit(SIGSYS) instead of force_sig(SIGSEGV) and force_sig(SIGSYS)? >>>> >>>> Looking at the code these cases are not expected to happen, so I would >>>> be surprised if userspace depends on any particular behaviour on the >>>> failure path so I think we can change this. >>> >>> Hi Eric, >>> >>> There is not really a good reason, and the use case that originated the >>> feature doesn't rely on it. >>> >>> Unless I'm missing yet another problem and others correct me, I think >>> it makes sense to change it as you described. >>> >>>> Is using do_exit in this way something you copied from seccomp? >>> >>> I'm not sure, its been a while, but I think it might be just that. The >>> first prototype of SUD was implemented as a seccomp mode. >> >> If at some point it becomes interesting we could relax >> "force_fatal_sig(SIGSEGV)" to instead say >> "force_sig_fault(SIGSEGV, SEGV_MAPERR, sd->selector)". >> >> I avoid doing that in this patch to avoid making it possible >> to catch currently uncatchable signals. >> >> Cc: Gabriel Krisman Bertazi <krisman@collabora.com> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Peter Zijlstra <peterz@infradead.org> >> Cc: Andy Lutomirski <luto@kernel.org> >> [1] https://lkml.kernel.org/r/87mtr6gdvi.fsf@collabora.com >> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> > > Yeah, looks good. Should be no visible behavior change. > > Reviewed-by: Kees Cook <keescook@chromium.org> >
I'm confused. Before this series, this error path would unconditionally kill the task (other than the race condition in force_sigsegv(), but at least a well-behaved task would get killed). Now a signal handler might be invoked, and it would be invoked after the syscall that triggered the fault got processed as a no-op. If the signal handler never returns, that's fine, but if the signal handler *does* return, the process might be in an odd state. For SIGSYS, this behavior is probably fine, but having SIGSEGV swallow a syscall seems like a mistake.
Maybe rewind (approximately!) the syscall? Or actually send SIGSYS? Or actually make the signal uncatchable?
--Andy
|  |