On 10/21/21 09:25, Kees Cook wrote:

On Wed, Oct 20, 2021 at 12:44:00PM -0500, Eric W. Biederman wrote:

quoted

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 [off-list ref] said [1]:

quoted

ebiederm@xmission.com (Eric W. Biederman) asked:

quoted

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.

quoted

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 <redacted>
Cc: Thomas Gleixner <redacted>
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" <redacted>

Yeah, looks good. Should be no visible behavior change.

Reviewed-by: Kees Cook <redacted>

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