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)

- Universal Stylus Interface (or any other new fancy feature that
  requires a new kernel API)

See [0].
Basically, USI pens are requiring a new kernel API because there are
some channels of communication our HID and input stack are not capable
of. Instead of using hidraw or creating new sysfs or ioctls, we can rely
on eBPF to have the kernel API controlled by the consumer and to not
impact the performances by waking up userspace every time there is an
event.

- Surface Dial

This device is a "puck" from Microsoft, basically a rotary dial with a
push button. The kernel already exports it as such but doesn't handle
the haptic feedback we can get out of it.
Furthermore, that device is not recognized by userspace and so it's a
nice paperwight in the end.

With eBPF, we can morph that device into a mouse, and convert the dial
events into wheel events. Also, we can set/unset the haptic feedback
from userspace. The convenient part of BPF makes it that the kernel
doesn't make any choice that would need to be reverted because that
specific userspace doesn't handle it properly or because that other
one expects it to be different.

- firewall

What if we want to prevent other users to access a specific feature of a
device? (think a possibly bonker firmware update entry popint)
With eBPF, we can intercept any HID command emitted to the device and
validate it or not.
This also allows to sync the state between the userspace and the
kernel/bpf program because we can intercept any incoming command.

- tracing

The last usage I have in mind is tracing events and all the fun we can
do we BPF to summarize and analyze events.
Right now, tracing relies on hidraw. It works well except for a couple
of issues:
 1. if the driver doesn't export a hidraw node, we can't trace anything
    (eBPF will be a "god-mode" there, so it might raise some eyebrows)
 2. hidraw doesn't catch the other process requests to the device, which
    means that we have cases where we need to add printks to the kernel
    to understand what is happening.


With that long introduction, here is the v1 of the support of eBPF in
HID.

I have targeted bpf-next here because the parts that will have the most
conflicts are in bpf. There might be a trivial minor conflict in
include/linux/hid.h with an other series I have pending[1].

I am relatively new to bpf, so having some feedback would be most very
welcome.

A couple of notes though:

- The series is missing a SEC("hid/driver_event") which would allow to
  intercept incoming requests to the device from anybody. I left it
  outside because it's not critical to have it from day one (we are more
  interested right now by the USI case above)

- I am still wondering how to integrate the tracing part:
  right now, if a bpf program is loaded before we start the tracer, we
  will see *modified* events in the tracer. However, it might be
  interesting to decide to see either unmodified (raw events from the
  device) or modified events.
  I think a flag might be able to solve that. The flag will control
  whether we add the new program at the beginning of the list or at the
  tail, but I am not sure if this is common practice in eBPF or if
  there is a better way.

Cheers,
Benjamin


[0] https://lore.kernel.org/linux-input/20211215134220.1735144-1-tero.kristo@linux.intel.com/
[1] https://lore.kernel.org/linux-input/20220203143226.4023622-1-benjamin.tissoires@redhat.com/


Benjamin Tissoires (6):
  HID: initial BPF implementation
  HID: bpf: allow to change the report descriptor from an eBPF program
  HID: bpf: add hid_{get|set}_data helpers
  HID: bpf: add new BPF type to trigger commands from userspace
  HID: bpf: tests: rely on uhid event to know if a test device is ready
  HID: bpf: add bpf_hid_raw_request helper function

 drivers/hid/Makefile                         |   1 +
 drivers/hid/hid-bpf.c                        | 327 +++++++++
 drivers/hid/hid-core.c                       |  31 +-
 include/linux/bpf-hid.h                      |  98 +++
 include/linux/bpf_types.h                    |   4 +
 include/linux/hid.h                          |  25 +
 include/uapi/linux/bpf.h                     |  33 +
 include/uapi/linux/bpf_hid.h                 |  56 ++
 kernel/bpf/Makefile                          |   3 +
 kernel/bpf/hid.c                             | 653 ++++++++++++++++++
 kernel/bpf/syscall.c                         |  12 +
 samples/bpf/.gitignore                       |   1 +
 samples/bpf/Makefile                         |   4 +
 samples/bpf/hid_mouse_kern.c                 |  91 +++
 samples/bpf/hid_mouse_user.c                 | 129 ++++
 tools/include/uapi/linux/bpf.h               |  33 +
 tools/lib/bpf/libbpf.c                       |   9 +
 tools/lib/bpf/libbpf.h                       |   2 +
 tools/lib/bpf/libbpf.map                     |   1 +
 tools/testing/selftests/bpf/prog_tests/hid.c | 685 +++++++++++++++++++
 tools/testing/selftests/bpf/progs/hid.c      | 149 ++++
 21 files changed, 2339 insertions(+), 8 deletions(-)
 create mode 100644 drivers/hid/hid-bpf.c
 create mode 100644 include/linux/bpf-hid.h
 create mode 100644 include/uapi/linux/bpf_hid.h
 create mode 100644 kernel/bpf/hid.c
 create mode 100644 samples/bpf/hid_mouse_kern.c
 create mode 100644 samples/bpf/hid_mouse_user.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/hid.c
 create mode 100644 tools/testing/selftests/bpf/progs/hid.c

-- 
2.35.1

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?  :)

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?

> - Universal Stylus Interface (or any other new fancy feature that
>   requires a new kernel API)
> 
> See [0].
> Basically, USI pens are requiring a new kernel API because there are
> some channels of communication our HID and input stack are not capable
> of. Instead of using hidraw or creating new sysfs or ioctls, we can rely
> on eBPF to have the kernel API controlled by the consumer and to not
> impact the performances by waking up userspace every time there is an
> event.

How is userspace supposed to interact with these devices in a unified
way then?  This would allow random new interfaces to be created, one
each for each device, and again, be a pain to track for a distro to keep
in sync.  And how are you going to keep the ebpf interface these
provides in sync with the userspace program?

> - Surface Dial
> 
> This device is a "puck" from Microsoft, basically a rotary dial with a
> push button. The kernel already exports it as such but doesn't handle
> the haptic feedback we can get out of it.
> Furthermore, that device is not recognized by userspace and so it's a
> nice paperwight in the end.
> 
> With eBPF, we can morph that device into a mouse, and convert the dial
> events into wheel events.

Why can't we do this in the kernel today?

> Also, we can set/unset the haptic feedback
> from userspace. The convenient part of BPF makes it that the kernel
> doesn't make any choice that would need to be reverted because that
> specific userspace doesn't handle it properly or because that other
> one expects it to be different.

Again, what would the new api for the haptic device be?  Who is going to
mantain that on the userspace side?  What library is going to use this?
Is libinput going to now be responsible for interacting this way with
the kernel?

> - firewall
> 
> What if we want to prevent other users to access a specific feature of a
> device? (think a possibly bonker firmware update entry popint)
> With eBPF, we can intercept any HID command emitted to the device and
> validate it or not.

This I like.

> This also allows to sync the state between the userspace and the
> kernel/bpf program because we can intercept any incoming command.
> 
> - tracing
> 
> The last usage I have in mind is tracing events and all the fun we can
> do we BPF to summarize and analyze events.
> Right now, tracing relies on hidraw. It works well except for a couple
> of issues:
>  1. if the driver doesn't export a hidraw node, we can't trace anything
>     (eBPF will be a "god-mode" there, so it might raise some eyebrows)
>  2. hidraw doesn't catch the other process requests to the device, which
>     means that we have cases where we need to add printks to the kernel
>     to understand what is happening.

Tracing is also nice, I like this too.

Anyway, I like the idea, I'm just worried we are pushing complexity out
into userspace which would make it "someone else's problem."  The job of
a kernel is to provide a way to abstract devices in a standard way.  To
force userspace to write a "new program per input device" would be a
total mess and a step backwards.

thanks,

greg k-h

On Thu, 2022-02-24 at 12:31 +0100, Greg KH 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?  :)
> 
> 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?

I don't quite understand how taking eBPF quirks for HID devices out of
the kernel tree is different from taking suspend quirks out of the
kernel tree:
https://www.spinics.net/lists/linux-usb/msg204506.html

On Thu, Feb 24, 2022 at 06:41:18PM +0100, Bastien Nocera wrote:
> On Thu, 2022-02-24 at 12:31 +0100, Greg KH 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?  :)
> > 
> > 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?
> 
> I don't quite understand how taking eBPF quirks for HID devices out of
> the kernel tree is different from taking suspend quirks out of the
> kernel tree:
> https://www.spinics.net/lists/linux-usb/msg204506.html

A list of all devices possible, and the policy decisions to make on
those devices, belongs in userspace, not in the kernel.  That's what the
hwdb contains.

Quirks in order to get the device to work properly is not a policy
decision, they are needed to get the device to work.  If you wish to
suspend it or not based on the vendor/product id, in order to possibly
save some more battery life on some types of systems, is something that
belongs in userspace.

If you want to replace the existing HID quirk tables with an ebpf
program that ships with the kernel, wonderful, I have no objection to
that.  If a user is required to download the external quirk table just
to get their device to work with the kernel, that's probably something
you don't want to do.

thanks,

greg k-h

Hi Greg,

Thanks for the quick answer :)

On Thu, Feb 24, 2022 at 12:31 PM Greg KH <gregkh@linuxfoundation.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?

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

>
> > - Universal Stylus Interface (or any other new fancy feature that
> >   requires a new kernel API)
> >
> > See [0].
> > Basically, USI pens are requiring a new kernel API because there are
> > some channels of communication our HID and input stack are not capable
> > of. Instead of using hidraw or creating new sysfs or ioctls, we can rely
> > on eBPF to have the kernel API controlled by the consumer and to not
> > impact the performances by waking up userspace every time there is an
> > event.
>
> How is userspace supposed to interact with these devices in a unified
> way then?  This would allow random new interfaces to be created, one
> each for each device, and again, be a pain to track for a distro to keep
> in sync.  And how are you going to keep the ebpf interface these
> provides in sync with the userspace program?

Right now, the idea we have is to export the USI specifics through
dbus. This has a couple of advantages: we are not tied to USI and can
"emulate" those parameters by storing them on disk instead of in the
pen, and this is easily accessible from all applications directly.

I am trying to push to have one implementation of that dbus service
with the Intel and ChromeOS folks so general linux doesn't have to
recreate it. But if you look at it, with hidraw nothing prevents
someone from writing such a library/daemon in its own world without
sharing it with anybody.

The main advantage of eBPF compared to hidraw is that you can analyse
the incoming event without waking userspace and only wake it up when
there is something noticeable.

In terms of random interfaces, yes, this is a good point. But the way
I see it is that we can provide one kernel API (eBPF for HID) which we
will maintain and not have to maintain forever a badly designed kernel
API for a specific device. Though also note that USI is a HID standard
(I think there is a second one), so AFAICT, the same bpf program
should be able to be generic enough to be cross vendor. So there will
be one provider only for USI.

>
> > - Surface Dial
> >
> > This device is a "puck" from Microsoft, basically a rotary dial with a
> > push button. The kernel already exports it as such but doesn't handle
> > the haptic feedback we can get out of it.
> > Furthermore, that device is not recognized by userspace and so it's a
> > nice paperwight in the end.
> >
> > With eBPF, we can morph that device into a mouse, and convert the dial
> > events into wheel events.
>
> Why can't we do this in the kernel today?

We can do this in the kernel, sure, but that means the kernel has to
make a choice.
Right now, the device is exported as a "rotary button". Userspace
should know what it is, and handle it properly.
Turns out that there are not so many developers who care about it, so
there is no implementation of it in userspace.

So the idea to morph it into a special mouse is interesting, but
suddenly we are lying to userspace about the device, and this can have
unanticipated consequences.

If we load a bpf program that morphs the device into a mouse, suddenly
the kernel is not the one responsible for that choice, but the user
is.

For instance, we could imagine a program that pops up a pie menu like
Windows does and enables/disables the haptic feedback based on what is
on screen.

With a kernel implementation, we need a driver with a config
parameter, a new haptic kernel API which is unlikely to be compatible
with the forcepad haptic API that Angela is working on :/

>
> > Also, we can set/unset the haptic feedback
> > from userspace. The convenient part of BPF makes it that the kernel
> > doesn't make any choice that would need to be reverted because that
> > specific userspace doesn't handle it properly or because that other
> > one expects it to be different.
>
> Again, what would the new api for the haptic device be?  Who is going to
> mantain that on the userspace side?  What library is going to use this?
> Is libinput going to now be responsible for interacting this way with
> the kernel?

In that particular case, I don't think the haptic API should be very
complex. On Windows, you only have a toggle: on/off.
And actually I'd love to see the haptic feedback enabled or disabled
based on the context: do you need one tick every 5 degrees? haptic
enabled, if not (smooth scrolling where every minimal step matters),
then haptic disabled.

Note that this is also entirely possible to be done in pure hidraw without BPF.

In terms of "who" that's up in the air. I am not using the device
enough to maintain such a tool (and definitively not skilled enough
for the UI part).

>
> > - firewall
> >
> > What if we want to prevent other users to access a specific feature of a
> > device? (think a possibly bonker firmware update entry popint)
> > With eBPF, we can intercept any HID command emitted to the device and
> > validate it or not.
>
> This I like.

Heh. It's a shame that it's the part I left out from the series :)

>
> > This also allows to sync the state between the userspace and the
> > kernel/bpf program because we can intercept any incoming command.
> >
> > - tracing
> >
> > The last usage I have in mind is tracing events and all the fun we can
> > do we BPF to summarize and analyze events.
> > Right now, tracing relies on hidraw. It works well except for a couple
> > of issues:
> >  1. if the driver doesn't export a hidraw node, we can't trace anything
> >     (eBPF will be a "god-mode" there, so it might raise some eyebrows)
> >  2. hidraw doesn't catch the other process requests to the device, which
> >     means that we have cases where we need to add printks to the kernel
> >     to understand what is happening.
>
> Tracing is also nice, I like this too.
>
> Anyway, I like the idea, I'm just worried we are pushing complexity out
> into userspace which would make it "someone else's problem."  The job of
> a kernel is to provide a way to abstract devices in a standard way.  To
> force userspace to write a "new program per input device" would be a
> total mess and a step backwards.
>

Yeah, I completely understand the view. However, please keep in mind
that most of it (though not firewall and some corner cases of tracing)
is already possible to do through hidraw.
One other example of that is SDL. We got Sony involved to create a
nice driver for the DualSense controller (the PS5 one), but they
simply ignore it and use plain HID (through hidraw). They have the
advantage of this being cross-platform and can provide a consistent
experience across platforms. And as a result, in the kernel, we have
to hands up the handling of the device whenever somebody opens a
hidraw node for those devices (Steam is also doing the same FWIW).

Which reminds me that I also have another use-case: joystick
dead-zone. You can have a small filter that configures the dead zone
and doesn't even wake up userspace for those hardware glitches...

Anyway, IOW, I think the bpf approach will allow kernel-like
performances of hidraw applications, and I would be more inclined to
ask people to move their weird issue in userspace thanks to that.

And I am also open to any suggestions on how to better handle your remarks :)

Cheers,
Benjamin

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@linuxfoundation.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.
[...]

On Thu, Feb 24, 2022 at 6:21 PM Yonghong Song <yhs@fb.com> wrote:
>
>
>
> 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@linuxfoundation.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.

Thanks. This is indeed interesting.
I am not sure the exact usage of it though :)

One thing I wonder too while we are on this topic, is it possible to
load a bpf program from the kernel directly, in the same way we can
request firmwares?

Because if we can do that, in my HID use case we could replace simple
drivers with bpf programs entirely and reduce the development cycle to
a bare minimum.

Cheers,
Benjamin


>
> >
> >>
> >> 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.
> [...]
>

On Fri, Feb 25, 2022 at 05:06:32PM +0100, Benjamin Tissoires wrote:
> On Thu, Feb 24, 2022 at 6:21 PM Yonghong Song <yhs@fb.com> wrote:
> >
> >
> >
> > 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@linuxfoundation.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.
> 
> Thanks. This is indeed interesting.
> I am not sure the exact usage of it though :)
> 
> One thing I wonder too while we are on this topic, is it possible to
> load a bpf program from the kernel directly, in the same way we can
> request firmwares?

We used to be able to do that, putting bpf programs inside a module.
But that might have gotten removed because no one actually used it.  I
thought it was a nice idea.

> Because if we can do that, in my HID use case we could replace simple
> drivers with bpf programs entirely and reduce the development cycle to
> a bare minimum.

How would the development cycle change?  You could get rid of many
in-kernel hid drivers and replace them with bpf code perhaps?  Maybe
that's a good use case :)

thanks,

greg k-h

On 2/25/22 8:06 AM, Benjamin Tissoires wrote:
> On Thu, Feb 24, 2022 at 6:21 PM Yonghong Song <yhs@fb.com> wrote:
>>
>>
>>
>> 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@linuxfoundation.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.
> 
> Thanks. This is indeed interesting.
> I am not sure the exact usage of it though :)
> 
> One thing I wonder too while we are on this topic, is it possible to
> load a bpf program from the kernel directly, in the same way we can
> request firmwares?

Yes. You can. See the example at kernel/bpf/preload directory.
The example will pin the link (holding a reference to the program)
into bpffs (implemented in kernel/bpf/inode.c).

Later on, in userspace, you can grab a fd from bpffs pinned link and use
BPF_LINK_UPDATE to update the program if you want. This way,
if your driver uses the link to get the program, they will
automatically get the new program in the next run.

> 
> Because if we can do that, in my HID use case we could replace simple
> drivers with bpf programs entirely and reduce the development cycle to
> a bare minimum. >
> Cheers,
> Benjamin
> 
> 
>>
>>>
>>>>
>>>> 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.
>> [...]
>>
>