linux-kernel - Re: [PATCH bpf-next v1 0/6] 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: <ed97e5e8-f2b8-569f-5319-36cd3d2b79b3@fb.com>
Date:   Thu, 24 Feb 2022 09:20:39 -0800
From:   Yonghong Song <yhs@...com>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Greg KH <gregkh@...uxfoundation.org>
CC:     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>,
        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>,
        Tero Kristo <tero.kristo@...ux.intel.com>,
        lkml <linux-kernel@...r.kernel.org>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        <netdev@...r.kernel.org>, <bpf@...r.kernel.org>,
        <linux-kselftest@...r.kernel.org>,
        Peter Hutterer <peter.hutterer@...hat.com>
Subject: Re: [PATCH bpf-next v1 0/6] Introduce eBPF support for HID devices



On 2/24/22 5:49 AM, Benjamin Tissoires wrote:
> Hi Greg,
> 
> Thanks for the quick answer :)
> 
> On Thu, Feb 24, 2022 at 12:31 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>>
>> On Thu, Feb 24, 2022 at 12:08:22PM +0100, Benjamin Tissoires wrote:
>>> Hi there,
>>>
>>> This series introduces support of eBPF for HID devices.
>>>
>>> I have several use cases where eBPF could be interesting for those
>>> input devices:
>>>
>>> - simple fixup of report descriptor:
>>>
>>> In the HID tree, we have half of the drivers that are "simple" and
>>> that just fix one key or one byte in the report descriptor.
>>> Currently, for users of such devices, the process of fixing them
>>> is long and painful.
>>> With eBPF, we could externalize those fixups in one external repo,
>>> ship various CoRe bpf programs and have those programs loaded at boot
>>> time without having to install a new kernel (and wait 6 months for the
>>> fix to land in the distro kernel)
>>
>> Why would a distro update such an external repo faster than they update
>> the kernel?  Many sane distros update their kernel faster than other
>> packages already, how about fixing your distro?  :)
> 
> Heh, I'm going to try to dodge the incoming rhel bullet :)
> 
> It's true that thanks to the work of the stable folks we don't have to
> wait 6 months for a fix to come in. However, I think having a single
> file to drop in a directory would be easier for development/testing
> (and distribution of that file between developers/testers) than
> requiring people to recompile their kernel.
> 
> Brain fart: is there any chance we could keep the validated bpf
> programs in the kernel tree?

Yes, see kernel/bpf/preload/iterators/iterators.bpf.c.

> 
>>
>> I'm all for the idea of using ebpf for HID devices, but now we have to
>> keep track of multiple packages to be in sync here.  Is this making
>> things harder overall?
> 
> Probably, and this is also maybe opening a can of worms. Vendors will
> be able to say "use that bpf program for my HID device because the
> firmware is bogus".
> 
> OTOH, as far as I understand, you can not load a BPF program in the
> kernel that uses GPL-declared functions if your BPF program is not
> GPL. Which means that if firmware vendors want to distribute blobs
> through BPF, either it's GPL and they have to provide the sources, or
> it's not happening.
> 
> I am not entirely clear on which plan I want to have for userspace.
> I'd like to have libinput on board, but right now, Peter's stance is
> "not in my garden" (and he has good reasons for it).
> So my initial plan is to cook and hold the bpf programs in hid-tools,
> which is the repo I am using for the regression tests on HID.
> 
> I plan on building a systemd intrinsic that would detect the HID
> VID/PID and then load the various BPF programs associated with the
> small fixes.
> Note that everything can not be fixed through eBPF, simply because at
> boot we don't always have the root partition mounted.
[...]