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: <CAHk-=whJETM0MHqWQKCVALBkJX-Th5471z5FW3gFJO5c73L6QA@mail.gmail.com>
Date:   Mon, 25 Oct 2021 16:15:44 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 13/20] signal: Implement force_fatal_sig

On Mon, Oct 25, 2021 at 3:41 PM Andy Lutomirski <luto@...nel.org> wrote:
>
> I'm rather nervous about all this, and I'm also nervous about the
> existing code.  A quick skim is finding plenty of code paths that assume
> force_sigsegv (or a do_exit that this series touches) are genuinely
> unrecoverable.

I was going to say "what are you talking about", because clearly Eric
kept it all fatal.

But then looked at that patch a bit more before I claimed you were wrong.

And yeah, Eric's force_fatal_sig() is completely broken.

It claims to force a fatal signal, but doesn't actually do that at
all, and is completely misnamed.

It just uses "force_sig_info_to_task()", which still allows user space
to catch signals - so it's not "fatal" in the least. It only punches
through SIG_IGN and blocked signals.

So yeah, that's broken.

I do still think that that could the behavior we possibly want for
that "can't write updated vm86 state back" situation, but for
something that is called "fatal", it really needs to be fatal.

            Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ