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]

Message-ID: <nycvar.YFH.7.76.2212020158420.6045@cbobk.fhfr.pm>
Date:   Fri, 2 Dec 2022 02:03:03 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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, 1 Dec 2022, Linus Torvalds 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.

Absolutely, me neither, quite the contrary -- I am quite happy to see 
HID-BPF happening, because it'll actually make life easier for everybody: 
for people with quirky hardware (trivial testing of fixes), for kernel 
developers (trivial testing of fixes), and for distributions (trivial 
distribution of fixes).

> 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.

Indeed. The whole rationale from Benjamin, explaining quite nicely why 
HID-BPF is a good thing, can be found in the very original, initial 
ancient cover letter:

	https://lore.kernel.org/lkml/20220224110828.2168231-1-benjamin.tissoires@redhat.com/

> 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.

Fully agreed. I unfortunately missed that particular aspect during review, 
and it popped up only after HID-BPF appeared in linux-next.

-- 
Jiri Kosina
SUSE Labs