linux-kernel - Re: [PATCH 14/20] exit/syscall_user_dispatch: Send ordinary signals on failure

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202110210925.9DEAF27CA@keescook>
Date:   Thu, 21 Oct 2021 09:25:36 -0700
From:   Kees Cook <keescook@...omium.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Gabriel Krisman Bertazi <krisman@...labora.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 14/20] exit/syscall_user_dispatch: Send ordinary signals
 on failure

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@...labora.com> said [1]:
> > ebiederm@...ssion.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@...labora.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Andy Lutomirski <luto@...nel.org>
> [1] https://lkml.kernel.org/r/87mtr6gdvi.fsf@collabora.com
> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>

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

Reviewed-by: Kees Cook <keescook@...omium.org>

-- 
Kees Cook