linux-hardening - Re: [REGRESSION] 5.16rc1: SA

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]

Date:   Fri, 19 Nov 2021 08:58:24 -0800
From:   Kyle Huey <me@...ehuey.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrea Righi <andrea.righi@...onical.com>,
        Shuah Khan <shuah@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Will Drewry <wad@...omium.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        linux-hardening@...r.kernel.org,
        "Robert O'Callahan" <rocallahan@...il.com>
Subject: Re: [REGRESSION] 5.16rc1: SA_IMMUTABLE breaks debuggers

On Fri, Nov 19, 2021 at 8:36 AM Kees Cook <keescook@...omium.org> wrote:
>
> On Fri, Nov 19, 2021 at 08:07:36AM -0800, Kyle Huey wrote:
> > On Thu, Nov 18, 2021 at 8:12 AM Eric W. Biederman <ebiederm@...ssion.com> wrote:
> > > Kyle thank you for your explanation of what breaks.  For future kernels
> > > I do need to do some work in this area and I will copy on the patches
> > > going forward.  In particular I strongly suspect that changing the
> > > sigaction and blocked state of the signal for these synchronous signals
> > > is the wrong thing to do, especially if the process is not killed.  I
> > > want to find another solution that does not break things but that also
> > > does not change the program state behind the programs back so things
> > > work differently under the debugger.
> >
> > The heads up in the future is appreciated, thanks.
>
> Yeah, I wonder if we could add you as a Reviewer in the MAINTAINERS file
> for ptrace/signal stuff? Then anyone using scripts/get_maintainers.pl
> would have a CC to you added.

I don't object to that. I guess we'll see how manageable the email load is.

> Also, are there more instructions about running the rr tests? When the
> execve refactoring was happening, I tried it[1], but the results were
> unclear (there seemed to be a lot of warnings and it made me think I'd
> done something wrong on my end).

It's a standard cmake test suite. The easiest way to run it is just to
run `make check`, wait a while, and see what gets printed out at the
end as failing.  There's a couple thousand tests that run and they
print all sorts of output ... some of them even crash intentionally to
make sure we can record specific types of crashes, so the ctest
pass/fail output at the very end is the only reliable indicator.

If you have specific issues you're seeing I'm happy to follow up here
or off list.

- Kyle

> -Kees
>
> [1] https://github.com/rr-debugger/rr/wiki/Building-And-Installing#tests
>
> --
> Kees Cook