Thread (22 messages) 22 messages, 2 authors, 2024-06-14

Re: [PATCH HID v3 15/16] HID: bpf: rework hid_bpf_ops_btf_struct_access

From: Alexei Starovoitov <hidden>
Date: 2024-06-10 18:39:48
Also in: bpf, linux-doc, linux-kselftest, lkml

On Sat, Jun 8, 2024 at 2:01 AM Benjamin Tissoires [off-list ref] wrote:
quoted hunk ↗ jump to hunk
The idea is to provide a list of stucts and their editable fields.

Currently no functional changes are introduced here, we will add some
more writeable fields in the next patch.

Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>

---

changes in v3:
- rewrote WRITE_RANGE macro to not deal with offset from the caller side

new in v2
---
 drivers/hid/bpf/hid_bpf_struct_ops.c | 91 +++++++++++++++++++++++++++---------
 1 file changed, 69 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/bpf/hid_bpf_struct_ops.c b/drivers/hid/bpf/hid_bpf_struct_ops.c
index 056d05d96962..b14eccb121e0 100644
--- a/drivers/hid/bpf/hid_bpf_struct_ops.c
+++ b/drivers/hid/bpf/hid_bpf_struct_ops.c
@@ -16,6 +16,7 @@
 #include <linux/hid_bpf.h>
 #include <linux/init.h>
 #include <linux/module.h>
+#include <linux/stddef.h>
 #include <linux/workqueue.h>
 #include "hid_bpf_dispatch.h"
@@ -52,40 +53,86 @@ static int hid_bpf_ops_check_member(const struct btf_type *t,
        return 0;
 }

+struct hid_bpf_offset_write_range {
+       const char *struct_name;
+       u32 struct_length;
+       u32 start;
+       u32 end;
+};
+
 static int hid_bpf_ops_btf_struct_access(struct bpf_verifier_log *log,
                                           const struct bpf_reg_state *reg,
                                           int off, int size)
 {
-       const struct btf_type *state;
-       const struct btf_type *t;
-       s32 type_id;
+#define WRITE_RANGE(_name, _field, _is_string)                                 \
+       {                                                                       \
+               .struct_name = #_name,                                          \
+               .struct_length = sizeof(struct _name),                          \
+               .start = offsetof(struct _name, _field),                        \
+               .end = offsetofend(struct _name, _field) - !!(_is_string),
so it works because char name[128]; had last byte as zero
before prog writes into it (in addition to potentially having
earlier 0 bytes), so the string is guaranteed
to be null-terminated regardless of what prog writes into it.
Right?

Overall:
Acked-by: Alexei Starovoitov <ast@kernel.org>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help