On Sat, Feb 26, 2022 at 8:31 AM Song Liu song@kernel.org wrote:
On Thu, Feb 24, 2022 at 3:09 AM Benjamin Tissoires benjamin.tissoires@redhat.com wrote:
The report descriptor is the dictionary of the HID protocol specific to the given device. Changing it is a common habit in the HID world, and making that feature accessible from eBPF allows to fix devices without having to install a new kernel.
Signed-off-by: Benjamin Tissoires benjamin.tissoires@redhat.com
[...]
diff --git a/include/linux/hid.h b/include/linux/hid.h index 8fd79011f461..66d949d10b78 100644 --- a/include/linux/hid.h +++ b/include/linux/hid.h @@ -1213,10 +1213,16 @@ do { \
#ifdef CONFIG_BPF u8 *hid_bpf_raw_event(struct hid_device *hdev, u8 *rd, int *size); +u8 *hid_bpf_report_fixup(struct hid_device *hdev, u8 *rdesc, unsigned int *size); int hid_bpf_module_init(void); void hid_bpf_module_exit(void); #else static inline u8 *hid_bpf_raw_event(struct hid_device *hdev, u8 *rd, int *size) { return rd; } +static inline u8 *hid_bpf_report_fixup(struct hid_device *hdev, u8 *rdesc,
unsigned int *size)+{
return kmemdup(rdesc, *size, GFP_KERNEL);+} static inline int hid_bpf_module_init(void) { return 0; } static inline void hid_bpf_module_exit(void) {} #endif diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h index 5978b92cacd3..a7a8d9cfcf24 100644 --- a/include/uapi/linux/bpf.h +++ b/include/uapi/linux/bpf.h @@ -999,6 +999,7 @@ enum bpf_attach_type { BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, BPF_PERF_EVENT, BPF_HID_DEVICE_EVENT,
BPF_HID_RDESC_FIXUP, __MAX_BPF_ATTACH_TYPE};
diff --git a/include/uapi/linux/bpf_hid.h b/include/uapi/linux/bpf_hid.h index 243ac45a253f..c0801d7174c3 100644 --- a/include/uapi/linux/bpf_hid.h +++ b/include/uapi/linux/bpf_hid.h @@ -18,6 +18,7 @@ struct hid_device; enum hid_bpf_event { HID_BPF_UNDEF = 0, HID_BPF_DEVICE_EVENT,
HID_BPF_RDESC_FIXUP,};
/* type is HID_BPF_DEVICE_EVENT */ @@ -26,12 +27,19 @@ struct hid_bpf_ctx_device_event { unsigned long size; };
+/* type is HID_BPF_RDESC_FIXUP */ +struct hid_bpf_ctx_rdesc_fixup {
__u8 data[HID_BPF_MAX_BUFFER_SIZE];unsigned long size;+};
This looks same as HID_BPF_DEVICE_EVENT, do we really need to separate the two?
I wanted to separate them because the other types have other requirements.
However, they all need a "data" with "size" associated. So I'll add data and size to the common definition of the struct, leaving only the specifics in the union (which means that DEVICE_EVENT and RDESC_FIXUP won't have a definition in the union). I'll see the look of it before submitting v2.
Cheers, Benjamin