linux-kernel - 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]

Date:   Fri, 20 May 2022 17:18:22 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        Christoph Hellwig <hch@...radead.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        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>,
        lkml <linux-kernel@...r.kernel.org>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Linux Doc Mailing List <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 4:56 AM Benjamin Tissoires
<benjamin.tissoires@...hat.com> wrote:
>
> As Greg mentioned in his reply, report descriptors fixups don't do
> much besides changing a memory buffer at probe time. So we can either
> have udev load the program, pin it and forget about it, or we can also
> have the kernel do that for us.
>
> So I envision the distribution to be hybrid:
> - for plain fixups where no userspace is required, we should
> distribute those programs in the kernel itself, in-tree.
> This series already implements pre-loading of BPF programs for the
> core part of HID-BPF, but I plan on working on some automation of
> pre-loading of these programs from the kernel itself when we need to
> do so.
>
> Ideally, the process would be:
> * user reports a bug
> * developer produces an eBPF program (and maybe compile it if the user
> doesn't have LLVM)
> * user tests/validates the fix without having to recompile anything
> * developer drops the program in-tree
> * some automated magic happens (still unclear exactly how to define
> which HID device needs which eBPF program ATM)
> * when the kernel sees this exact same device (BUS/VID/PID/INTERFACE)
> it loads the fixup
>
> - the other part of the hybrid solution is for when userspace is
> heavily involved (because it exports a new dbus interface for that
> particular feature on this device). We can not really automatically
> preload the BPF program because we might not have the user in front of
> it.
> So in that case, the program would be hosted alongside the
> application, out-of-the-tree, but given that to be able to call kernel
> functions you need to be GPL, some public distribution of the sources
> is required.

Agree with everything you've said earlier.
Just one additional comment:
By default the source code is embedded in bpf objects.
Here is an example.
$ bpftool prog dump jited id 3927008|head -50
void cwnd_event(long long unsigned int * ctx):
bpf_prog_9b9adc0a36a25303_cwnd_event:
; void BPF_STRUCT_OPS(cwnd_event, struct sock* sk, enum tcp_ca_event ev) {
   0:    nopl   0x0(%rax,%rax,1)
   5:    xchg   %ax,%ax
...
; switch (ev) {
  25:    mov    %r14d,%edi
  28:    add    $0xfffffffc,%edi
...
; ca->loss_cwnd = tp->snd_cwnd;
  4a:    mov    %edi,0x18(%r13)
  4e:    mov    $0x2,%edi
; tp->snd_ssthresh = max(tp->snd_cwnd >> 1U, 2U);
  53:    test   %rbx,%rbx
  56:    jne    0x000000000000005c

It's not the full source, of course, but good enough in practice
for a person to figure out what program is doing.