On Jun 10 2024, Alexei Starovoitov wrote:
On Sat, Jun 8, 2024 at 2:01 AM Benjamin Tissoires bentiss@kernel.org wrote:
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?
Yeah, struct hid_device is created through hid_allocate_device(), which does a kzalloc. Then all operations are supposedly safe in the current transport layers, so the last byte should always be \0.
Overall: Acked-by: Alexei Starovoitov ast@kernel.org
Thanks a lot.
I might send a v4 or not depending if I get other reviews, but I'll make sure to take your nitpick in 3/16 into account (cast kdata/udate in the beginning of the function to make the lines shorter and less verbose).
Cheers, Benjamin