linux-kernel - Re: [PATCH] error-injection: Add prompt for function error injection

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:   Thu, 1 Dec 2022 16:57:30 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chris Mason <clm@...a.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Borislav Petkov <bp@...en8.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Kees Cook <keescook@...omium.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        KP Singh <kpsingh@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Florent Revest <revest@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>
Subject: Re: [PATCH] error-injection: Add prompt for function error injection

On Thu, Dec 1, 2022 at 4:46 PM Jiri Kosina <jikos@...nel.org> wrote:
>
> Anyway, I believe [1] that ERROR_INJECTION has been designed as a
> debugging feature in the first place, and should stay so. After figuring
> out now that HID-BPF actually has hard dependence on it, I fully agree [2]
> that the series should be ditched for 6.2 and will work with Benjamin to
> have it removed from current hid.git#for-next.

I do think that it is interesting to have a "let's have a bpf
insertion hook here", so I'm not against the _concept_ of HID doing
that.

It's not so different from user-mode drivers, after all, which we also
have. A kind of half-way state where we have a kernel driver, but one
that may need custom site-specific (or machine-specific) tweaks.

So I don't want to come across as being against having bpf used for
tuning some HID issue (and I can imagine it making sense in other
places that have machine-specific tweaks - I'm thinking of all the
thermal probe or pincontrol mess where sometimes you have GPIO's or
motherboard thermal sensors etc that are literally "user connected it
to X").

But the notion that we'd use some error injection framework for it,
and that you'd mix those concepts up - *that* I really think is just
horrendous.

Because even if you end up using some common infrastructure code, we
really should separate things out much better.

              Linus