Centos-kernel-stream-9/include/linux/hid_bpf.h

239 lines
8.2 KiB
C
Raw Permalink Normal View History

HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
/* SPDX-License-Identifier: GPL-2.0+ */
#ifndef __HID_BPF_H
#define __HID_BPF_H
HID: bpf: rework how programs are attached and stored in the kernel Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit 4b9a3f49f02bf682eedfde23ef56a8df82c1e5d2 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Fri Jan 13 10:09:32 2023 +0100 HID: bpf: rework how programs are attached and stored in the kernel Previously, HID-BPF was relying on a bpf tracing program to be notified when a program was released from userspace. This is error prone, as LLVM sometimes inline the function and sometimes not. So instead of messing up with the bpf prog ref count, we can use the bpf_link concept which actually matches exactly what we want: - a bpf_link represents the fact that a given program is attached to a given HID device - as long as the bpf_link has fd opened (either by the userspace program still being around or by pinning the bpf object in the bpffs), the program stays attached to the HID device - once every user has closed the fd, we get called by hid_bpf_link_release() that we no longer have any users, and we can disconnect the program to the device in 2 passes: first atomically clear the bit saying that the link is active, and then calling release_work in a scheduled work item. This solves entirely the problems of BPF tracing not showing up and is definitely cleaner. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:57:39 +00:00
#include <linux/bpf.h>
#include <linux/mutex.h>
#include <linux/srcu.h>
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
#include <uapi/linux/hid.h>
struct hid_device;
/*
* The following is the user facing HID BPF API.
*
* Extra care should be taken when editing this part, as
* it might break existing out of the tree bpf programs.
*/
/**
* struct hid_bpf_ctx - User accessible data for all HID programs
*
* ``data`` is not directly accessible from the context. We need to issue
* a call to hid_bpf_get_data() in order to get a pointer to that field.
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
*
* @hid: the &struct hid_device representing the device itself
* @allocated_size: Allocated size of data.
*
* This is how much memory is available and can be requested
* by the HID program.
* Note that for ``HID_BPF_RDESC_FIXUP``, that memory is set to
* ``4096`` (4 KB)
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
* @size: Valid data in the data field.
*
* Programs can get the available valid size in data by fetching this field.
* Programs can also change this value by returning a positive number in the
* program.
* To discard the event, return a negative error code.
*
* ``size`` must always be less or equal than ``allocated_size`` (it is enforced
* once all BPF programs have been run).
* @retval: Return value of the previous program.
*
* ``hid`` and ``allocated_size`` are read-only, ``size`` and ``retval`` are read-write.
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
*/
struct hid_bpf_ctx {
struct hid_device *hid;
__u32 allocated_size;
union {
__s32 retval;
__s32 size;
};
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
};
/*
* Below is HID internal
*/
#define HID_BPF_MAX_PROGS_PER_DEV 64
#define HID_BPF_FLAG_MASK (((HID_BPF_FLAG_MAX - 1) << 1) - 1)
struct hid_report_enum;
struct hid_ops {
struct hid_report *(*hid_get_report)(struct hid_report_enum *report_enum, const u8 *data);
int (*hid_hw_raw_request)(struct hid_device *hdev,
unsigned char reportnum, __u8 *buf,
size_t len, enum hid_report_type rtype,
enum hid_class_request reqtype,
HID: bpf: fix gcc warning and unify __u64 into u64 JIRA: https://issues.redhat.com/browse/RHEL-53898 Upstream Status: since v6.12 Tested: with the hid-tools test suite and some hardware commit 762ced1630a97a457ad2fd5f5a36849009808431 Author: Benjamin Tissoires <bentiss@kernel.org> Date: Mon Jul 1 14:39:50 2024 +0200 HID: bpf: fix gcc warning and unify __u64 into u64 I've got multiple reports of: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]. Let's use the same trick than kernel/bpf/helpers.c to shut up that warning. Even if we were on an architecture with addresses on more than 64 bits, this isn't much of an issue as the address is not used as a pointer, but as an hash and the caller is not supposed to go back to the kernel address ever. And while we change those, make sure we use u64 instead of __u64 for consistency Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406280633.OPB5uIFj-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282304.UydSVncq-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282242.Fk738zzy-lkp@intel.com/ Reported-by: Mirsad Todorovac <mtodorovac69@gmail.com> Fixes: 67eccf151d76 ("HID: add source argument to HID low level functions") Link: https://patch.msgid.link/20240701-fix-cki-v2-2-20564e2e1393@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2024-11-29 16:23:09 +00:00
u64 source, bool from_bpf);
int (*hid_hw_output_report)(struct hid_device *hdev, __u8 *buf, size_t len,
HID: bpf: fix gcc warning and unify __u64 into u64 JIRA: https://issues.redhat.com/browse/RHEL-53898 Upstream Status: since v6.12 Tested: with the hid-tools test suite and some hardware commit 762ced1630a97a457ad2fd5f5a36849009808431 Author: Benjamin Tissoires <bentiss@kernel.org> Date: Mon Jul 1 14:39:50 2024 +0200 HID: bpf: fix gcc warning and unify __u64 into u64 I've got multiple reports of: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]. Let's use the same trick than kernel/bpf/helpers.c to shut up that warning. Even if we were on an architecture with addresses on more than 64 bits, this isn't much of an issue as the address is not used as a pointer, but as an hash and the caller is not supposed to go back to the kernel address ever. And while we change those, make sure we use u64 instead of __u64 for consistency Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406280633.OPB5uIFj-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282304.UydSVncq-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282242.Fk738zzy-lkp@intel.com/ Reported-by: Mirsad Todorovac <mtodorovac69@gmail.com> Fixes: 67eccf151d76 ("HID: add source argument to HID low level functions") Link: https://patch.msgid.link/20240701-fix-cki-v2-2-20564e2e1393@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2024-11-29 16:23:09 +00:00
u64 source, bool from_bpf);
int (*hid_input_report)(struct hid_device *hid, enum hid_report_type type,
u8 *data, u32 size, int interrupt, u64 source, bool from_bpf,
bool lock_already_taken);
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
struct module *owner;
const struct bus_type *bus_type;
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
};
extern struct hid_ops *hid_ops;
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
/**
* struct hid_bpf_ops - A BPF struct_ops of callbacks allowing to attach HID-BPF
* programs to a HID device
* @hid_id: the HID uniq ID to attach to. This is writeable before ``load()``, and
* cannot be changed after
* @flags: flags used while attaching the struct_ops to the device. Currently only
* available value is %0 or ``BPF_F_BEFORE``.
* Writeable only before ``load()``
*/
struct hid_bpf_ops {
/* hid_id needs to stay first so we can easily change it
* from userspace.
*/
int hid_id;
u32 flags;
/* private: do not show up in the docs */
struct list_head list;
/* public: rest should show up in the docs */
/**
* @hid_device_event: called whenever an event is coming in from the device
*
* It has the following arguments:
*
* ``ctx``: The HID-BPF context as &struct hid_bpf_ctx
*
* Return: %0 on success and keep processing; a positive
* value to change the incoming size buffer; a negative
* error code to interrupt the processing of this event
*
* Context: Interrupt context.
*/
int (*hid_device_event)(struct hid_bpf_ctx *ctx, enum hid_report_type report_type,
HID: bpf: fix gcc warning and unify __u64 into u64 JIRA: https://issues.redhat.com/browse/RHEL-53898 Upstream Status: since v6.12 Tested: with the hid-tools test suite and some hardware commit 762ced1630a97a457ad2fd5f5a36849009808431 Author: Benjamin Tissoires <bentiss@kernel.org> Date: Mon Jul 1 14:39:50 2024 +0200 HID: bpf: fix gcc warning and unify __u64 into u64 I've got multiple reports of: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]. Let's use the same trick than kernel/bpf/helpers.c to shut up that warning. Even if we were on an architecture with addresses on more than 64 bits, this isn't much of an issue as the address is not used as a pointer, but as an hash and the caller is not supposed to go back to the kernel address ever. And while we change those, make sure we use u64 instead of __u64 for consistency Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202406280633.OPB5uIFj-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282304.UydSVncq-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202406282242.Fk738zzy-lkp@intel.com/ Reported-by: Mirsad Todorovac <mtodorovac69@gmail.com> Fixes: 67eccf151d76 ("HID: add source argument to HID low level functions") Link: https://patch.msgid.link/20240701-fix-cki-v2-2-20564e2e1393@kernel.org Signed-off-by: Benjamin Tissoires <bentiss@kernel.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2024-11-29 16:23:09 +00:00
u64 source);
/**
* @hid_rdesc_fixup: called when the probe function parses the report descriptor
* of the HID device
*
* It has the following arguments:
*
* ``ctx``: The HID-BPF context as &struct hid_bpf_ctx
*
* Return: %0 on success and keep processing; a positive
* value to change the incoming size buffer; a negative
* error code to interrupt the processing of this device
*/
int (*hid_rdesc_fixup)(struct hid_bpf_ctx *ctx);
/**
* @hid_hw_request: called whenever a hid_hw_raw_request() call is emitted
* on the HID device
*
* It has the following arguments:
*
* ``ctx``: The HID-BPF context as &struct hid_bpf_ctx
*
* ``reportnum``: the report number, as in hid_hw_raw_request()
*
* ``rtype``: the report type (``HID_INPUT_REPORT``, ``HID_FEATURE_REPORT``,
* ``HID_OUTPUT_REPORT``)
*
* ``reqtype``: the request
*
* ``source``: a u64 referring to a uniq but identifiable source. If %0, the
* kernel itself emitted that call. For hidraw, ``source`` is set
* to the associated ``struct file *``.
*
* Return: %0 to keep processing the request by hid-core; any other value
* stops hid-core from processing that event. A positive value should be
* returned with the number of bytes returned in the incoming buffer; a
* negative error code interrupts the processing of this call.
*/
int (*hid_hw_request)(struct hid_bpf_ctx *ctx, unsigned char reportnum,
enum hid_report_type rtype, enum hid_class_request reqtype,
u64 source);
/**
* @hid_hw_output_report: called whenever a hid_hw_output_report() call is emitted
* on the HID device
*
* It has the following arguments:
*
* ``ctx``: The HID-BPF context as &struct hid_bpf_ctx
*
* ``source``: a u64 referring to a uniq but identifiable source. If %0, the
* kernel itself emitted that call. For hidraw, ``source`` is set
* to the associated ``struct file *``.
*
* Return: %0 to keep processing the request by hid-core; any other value
* stops hid-core from processing that event. A positive value should be
* returned with the number of bytes written to the device; a negative error
* code interrupts the processing of this call.
*/
int (*hid_hw_output_report)(struct hid_bpf_ctx *ctx, u64 source);
/* private: do not show up in the docs */
struct hid_device *hdev;
};
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
/* stored in each device */
struct hid_bpf {
u8 *device_data; /* allocated when a bpf program of type
* SEC(f.../hid_bpf_device_event) has been attached
* to this HID device
*/
u32 allocated_data;
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
bool destroyed; /* prevents the assignment of any progs */
struct hid_bpf_ops *rdesc_ops;
struct list_head prog_list;
struct mutex prog_list_lock; /* protects prog_list update */
struct srcu_struct srcu; /* protects prog_list read-only access */
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
};
#ifdef CONFIG_HID_BPF
u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type, u8 *data,
u32 *size, int interrupt, u64 source, bool from_bpf);
int dispatch_hid_bpf_raw_requests(struct hid_device *hdev,
unsigned char reportnum, __u8 *buf,
u32 size, enum hid_report_type rtype,
enum hid_class_request reqtype,
u64 source, bool from_bpf);
int dispatch_hid_bpf_output_report(struct hid_device *hdev, __u8 *buf, u32 size,
u64 source, bool from_bpf);
int hid_bpf_connect_device(struct hid_device *hdev);
void hid_bpf_disconnect_device(struct hid_device *hdev);
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
void hid_bpf_destroy_device(struct hid_device *hid);
int hid_bpf_device_init(struct hid_device *hid);
u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size);
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
#else /* CONFIG_HID_BPF */
static inline u8 *dispatch_hid_bpf_device_event(struct hid_device *hid, enum hid_report_type type,
u8 *data, u32 *size, int interrupt,
u64 source, bool from_bpf) { return data; }
static inline int dispatch_hid_bpf_raw_requests(struct hid_device *hdev,
unsigned char reportnum, u8 *buf,
u32 size, enum hid_report_type rtype,
enum hid_class_request reqtype,
u64 source, bool from_bpf) { return 0; }
static inline int dispatch_hid_bpf_output_report(struct hid_device *hdev, __u8 *buf, u32 size,
u64 source, bool from_bpf) { return 0; }
static inline int hid_bpf_connect_device(struct hid_device *hdev) { return 0; }
static inline void hid_bpf_disconnect_device(struct hid_device *hdev) {}
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
static inline void hid_bpf_destroy_device(struct hid_device *hid) {}
static inline int hid_bpf_device_init(struct hid_device *hid) { return 0; }
static inline u8 *call_hid_bpf_rdesc_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size)
{
return kmemdup(rdesc, *size, GFP_KERNEL);
}
HID: initial BPF implementation Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166610 Upstream Status: since v6.3 Tested: with the hid-tools test suite and some hardware commit f5c27da4e3c8a2e42fb4f41a0c685debcb9af294 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Nov 3 16:57:44 2022 +0100 HID: initial BPF implementation Declare an entry point that can use fmod_ret BPF programs, and also an API to access and change the incoming data. A simpler implementation would consist in just calling hid_bpf_device_event() for any incoming event and let users deal with the fact that they will be called for any event of any device. The goal of HID-BPF is to partially replace drivers, so this situation can be problematic because we might have programs which will step on each other toes. For that, we add a new API hid_bpf_attach_prog() that can be called from a syscall and we manually deal with a jump table in hid-bpf. Whenever we add a program to the jump table (in other words, when we attach a program to a HID device), we keep the number of time we added this program in the jump table so we can release it whenever there are no other users. HID devices have an RCU protected list of available programs in the jump table, and those programs are called one after the other thanks to bpf_tail_call(). To achieve the detection of users losing their fds on the programs we attached, we add 2 tracing facilities on bpf_prog_release() (for when a fd is closed) and bpf_free_inode() (for when a pinned program gets unpinned). Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
2023-05-23 13:54:23 +00:00
#endif /* CONFIG_HID_BPF */
#endif /* __HID_BPF_H */