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] [day] [month] [year] [list]
Date:   Mon, 12 Dec 2022 22:43:37 +0100
From:   KP Singh <>
To:     Steven Rostedt <>
Cc:     Masami Hiramatsu <>,
        Alexei Starovoitov <>,
        LKML <>, bpf <>,
        Borislav Petkov <>,
        Linus Torvalds <>,
        Andrew Morton <>,
        Peter Zijlstra <>,
        Kees Cook <>,
        Josh Poimboeuf <>,
        Mark Rutland <>,
        Florent Revest <>,
        Greg Kroah-Hartman <>,
        Christoph Hellwig <>,
        Chris Mason <>
Subject: Re: [PATCH v2] panic: Taint kernel if fault injection has been used

On Sun, Dec 11, 2022 at 6:02 PM Steven Rostedt <> wrote:
> On Sun, 11 Dec 2022 08:49:01 +0100
> KP Singh <> 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 think this is already better as it gives the recipient of the stack
trace more information to ask more questions and see if the BPF
programs are relevant to the stack trace and engage further.

> 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

Powered by blists - more mailing lists