linux-kernel - Re: [RFC bpf-next v4 0/7] Introduce eBPF support for HID devices (new attempt)

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: <20220426040314.ez3cdpv2w45vbgkk@MBP-98dd607d3435.dhcp.thefacebook.com>
Date:   Mon, 25 Apr 2022 21:03:14 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     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>,
        Tero Kristo <tero.kristo@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [RFC bpf-next v4 0/7] Introduce eBPF support for HID devices
 (new attempt)

On Thu, Apr 21, 2022 at 04:07:33PM +0200, Benjamin Tissoires wrote:
> Hi,
> 
> so after the reviews from v3, and some discussion with Alexei, I am
> back with a new version of HID-BPF.
> 
> This version is not complete (thus the RFC), but I'd like to share
> it now to get initial feedback, in case I am too far from the actual
> goal.
> 
> FTR, the goal is to provide some changes in the core verifier/btf so
> that we can plug in HID-BPF independently from BPF core. This way we can
> extend it without having to care about bpf-next.

Overall looks great. imo much cleaner, simpler and more extensible
than the earlier versions.
The bpf core extensions are nicely contained and HID side can be
worked on in parallel.

> The things I am not entirely sure are:
> - do we need only fentry/fexit/fmod_ret BPF program types or should
>   programs that modify the data stream use a different kind?

Probably not. I'll reply in patch 2.

> - patch 3/7 is probably not the correct approach (see comments in the
>   patch itself)
> 
> We are missing quite a few bits here:
> - selftests for patches 1 to 4
> - add the ability to attach a program to a struct device, and run that
>   program only for that struct device

yes. That is still to be figured out.

> - when running through bpf_prog_test_run_opts, how can we ensure we are
>   talking to the correct device? (I have a feeling this is linked to the
>   previous point)
> - how can we reconnect the device when a report descriptor fixup BPF
>   program is loaded (would it make sense to allow some notifications on
>   when a BPF program is attached/detached to a device, and which
>   function have been traced?)

Not sure I follow. What kind of notification do you have in mind?
To user space?