[<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