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, 2 Dec 2022 01:46:39 +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:

> > The hid-bpf framework depends on it.
> 
> Ok, this is completely unacceptably disgusting hack.
> 
> That needs fixing.
> 
> > Either hid-bpf or bpf core can add
> > "depends on FUNCTION_ERROR_INJECTION"
> 
> No, it needs to be narrowed down a lot. Nobody sane wants error
> injection just because they want some random HID thing.
> 
> And no, BPF shouldn't need it either.
> 
> This needs to be narrowed down to the point where HID can say "I want
> *this* particular call to be able to be a bpf call.
> 
> Stop this crazy "bpf / hid needs error injection" when that then
> implies a _lot_ more than that, plus is documented to be something
> entirely different anyway.
> 
> I realize that HID has mis-used the "we could just use error injection
> here to instead insert random bpf code", but that's a complete hack.
> 
> Plus it seems to happily not even have made it into mainline anyway,
> and only exists in linux-next. Let's head that disgusting hack off at
> the pass.
> 
> I'm going to apply Steven's patch, because honestly, we need to fix
> this disgusting mess *before* it gets to mainline, rather than say
> "oh, we already have broken users in next, so let's bend over
> backwards for that".
> 
> The code is called "error injection", not "random bpf extension"

Seems like quite a few parallel threads are currently going on about this, 
so it's a little bit hard to catch up for me as I am apparently CCed only 
on some of them.

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.

[1] https://lore.kernel.org/all/nycvar.YEU.7.76.2211211716270.27249@gjva.wvxbf.pm/
[2] https://lore.kernel.org/lkml/nycvar.YFH.7.76.2212020135390.6045@cbobk.fhfr.pm/

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ