netdev - Re: [PATCH bpf-next v5 00/17] Introduce eBPF support for HID devices

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: <YoX904CAFOAfWeJN@kroah.com>
Date:   Thu, 19 May 2022 10:20:35 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Jiri Kosina <jikos@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, Shuah Khan <shuah@...nel.org>,
        Dave Marchevsky <davemarchevsky@...com>,
        Joe Stringer <joe@...ium.io>, Jonathan Corbet <corbet@....net>,
        Tero Kristo <tero.kristo@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        linux-kselftest@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH bpf-next v5 00/17] Introduce eBPF support for HID devices

On Thu, May 19, 2022 at 01:10:48AM -0700, Christoph Hellwig wrote:
> > The logic is the following (see also the last patch for some more
> > documentation):
> > - hid-bpf first preloads a BPF program in the kernel that does a few
> >   things:
> >    * find out which attach_btf_id are associated with our trace points
> >    * adds a bpf_tail_call() BPF program that I can use to "call" any
> >      other BPF program stored into a jump table
> >    * monitors the releases of struct bpf_prog, and when there are no
> >      other users than us, detach the bpf progs from the HID devices
> > - users then declare their tracepoints and then call
> >   hid_bpf_attach_prog() in a SEC("syscall") program
> > - hid-bpf then calls multiple time the bpf_tail_call() program with a
> >   different index in the jump table whenever there is an event coming
> >   from a matching HID device
> 
> So driver abstractions like UDI are now perfectly fine as long as they
> are written using a hip new VM?

Ugh, don't mention UDI, that's a bad flashback...

> This whole idea seems like a bad idea, against the Linux spirit and
> now actually useful - it is totally trivial to write a new HID
> driver alreay, and if it isn't in some cases we need to fix that.
> 
> So a big fat NAK to the idea of using eBPF for actual driver logic.

I thought the goal here was to move a lot of the quirk handling and
"fixup the broken HID decriptors in this device" out of kernel .c code
and into BPF code instead, which this patchset would allow.

So that would just be exception handling.  I don't think you can write a
real HID driver here at all, but I could be wrong as I have not read the
new patchset (older versions of this series could not do that.)

thanks,

greg k-h