Received-SPF: pass (google.com: domain of linux-kernel+bounces-210299-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Tue, 11 Jun 2024 18:57:16 +0200
From: Benjamin Tissoires <bentiss@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>, Jiri Kosina <jikos@kernel.org>, 
	Jonathan Corbet <corbet@lwn.net>, Alexei Starovoitov <ast@kernel.org>, 
	"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, bpf <bpf@vger.kernel.org>, 
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>, "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH HID v3 15/16] HID: bpf: rework
 hid_bpf_ops_btf_struct_access
Message-ID: <lqyoauxovbelrzbnohxqc7tluibn72vqlps4lz4dxsxmgpyli3@qwzt4etxntyj>
References: <20240608-hid_bpf_struct_ops-v3-0-6ac6ade58329@kernel.org>
 <20240608-hid_bpf_struct_ops-v3-15-6ac6ade58329@kernel.org>
 <CAADnVQLCyEZMyThCH6QNopBbWbNcpR+h2AaLhT0apEO7pOWrRQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAADnVQLCyEZMyThCH6QNopBbWbNcpR+h2AaLhT0apEO7pOWrRQ@mail.gmail.com>

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