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  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]
Date:   Wed, 17 Nov 2021 17:11:14 -0800
From:   Linus Torvalds <>
To:     Kyle Huey <>
Cc:     Kees Cook <>,
        "Eric W. Biederman" <>,
        Andrea Righi <>,
        Shuah Khan <>,
        Alexei Starovoitov <>,
        Andy Lutomirski <>,
        Will Drewry <>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <>, bpf <>,
        open list <>,,
        "Robert O'Callahan" <>
Subject: Re: [REGRESSION] 5.16rc1: SA_IMMUTABLE breaks debuggers

On Wed, Nov 17, 2021 at 4:37 PM Kyle Huey <> wrote:
> This fixes most of the issues with rr, but it still changes the ptrace
> behavior for the double-SIGSEGV case

Hmm. I think that's because of how "force_sigsgv()" works.

I absolutely detest that function.

So we have signal_setup_done() doing that

        if (failed)

and then force_sigsegv() has that completely insane

        if (sig == SIGSEGV)


And I think I know the _reason_ for that complete insanity: when
SIGSEGV takes a SIGSEGV, and there is a handler, we need to stop
trying to send more SIGSEGV's.

But it does mean that with my change, that second SIGSEGV now ends up
being that SA_IMMUTABLE kind, so yeah, it broke the debugger test -
where catching the second SIGSEGV is actually somewhat sensible (ok,
not really, but at least understandable)

End result: I think we want not a boolean, but a three-way choice for
that force_sig_info_to_task() thing:

 - unconditionally fatal (for things that just want to force an exit
and used to do do_exit())

 - ignore valid and unblocked handler (for that SIGSEGV recursion
case, aka force "sigdfl")

 - catching signal ok

So my one-liner isn't sufficient. It wants some kind of nasty enum.

At least the enum can be entirely internal to kernel/signal.c, I
think. No need to expose this all to anything else.


Powered by blists - more mailing lists