linux-kernel - Re: [PATCH v2] panic: Taint kernel if fault injection has been used

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:   Sun, 11 Dec 2022 12:02:26 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     KP Singh <kpsingh@...nel.org>
Cc:     Masami Hiramatsu <mhiramat@...nel.org>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Florent Revest <revest@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Chris Mason <clm@...a.com>
Subject: Re: [PATCH v2] panic: Taint kernel if fault injection has been used

On Sun, 11 Dec 2022 08:49:01 +0100
KP Singh <kpsingh@...nel.org> wrote:

> Let's take a step back and focus on solving debuggability and
> introspection as we clearly have some perception issues about taints
> in the community. (distro maintainers, users) before we go and add
> more taints.

Note, you will likely get the same push back if the dump includes bpf
programs known to change the return of a function that may be involved
with the bug report. That is, if a crash is reported to code I
maintain, and I see that the bug report includes a list of BPF programs
that can modify the return of a function, and one of those functions
could affect the place that crashed, I'd push back and ask if the crash
could be done without that BPF program loaded, regardless of taints.

I agree that a taint is just a hint and it can include something that
caused the bug or it may not. I would like to see more details in how
the crashed kernel was configured. That includes loaded BPF programs
(just like we include loaded modules). And if any BPF program modifies
a core function (outside of syscall returns) I'd be a bit suspect of
what happened.

I also agree that if a function that checks error paths fails, it
should be fixed, but knowing that the error path was caused by fault
injection will prevent the wasted effort that most developers will go
through to find out why the error path was hit in the first place.

-- Steve