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 20:32:57 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chris Mason <clm@...a.com>, 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 Fri, 2 Dec 2022 02:03:03 +0100 (CET)
Jiri Kosina <jikos@...nel.org> wrote:

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

Full disclosure, I'm not against a bpf_hook either. In fact, I think I even
stated something to that effect, like adding a bpf_hook annotation to
functions or whatever, so that people can plainly see that the function can
have bpf attached to it.

I just *hate* the ad hoc way of using infrastructure for other purposes
than what they were designed for.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ