[lkml]   [2021]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 14/20] exit/syscall_user_dispatch: Send ordinary signals on failure
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 <> said [1]:
>>> (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 <>
>> Cc: Thomas Gleixner <>
>> Cc: Peter Zijlstra <>
>> Cc: Andy Lutomirski <>
>> [1]
>> Signed-off-by: "Eric W. Biederman" <>
> Yeah, looks good. Should be no visible behavior change.
> Reviewed-by: Kees Cook <>

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?


 \ /
  Last update: 2021-10-26 00:33    [W:0.140 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site