netdev - Re: [PATCH bpf-next 1/2] bpf: allow __sk_buff tstamp in BPF_PROG_TEST

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191015234552.GC1897241@mini-arch>
Date:   Tue, 15 Oct 2019 16:45:52 -0700
From:   Stanislav Fomichev <sdf@...ichev.me>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>
Subject: Re: [PATCH bpf-next 1/2] bpf: allow __sk_buff tstamp in
 BPF_PROG_TEST_RUN

On 10/15, Alexei Starovoitov wrote:
> On Tue, Oct 15, 2019 at 4:15 PM Andrii Nakryiko
> <andrii.nakryiko@...il.com> wrote:
> >
> > On Tue, Oct 15, 2019 at 2:26 PM Stanislav Fomichev <sdf@...gle.com> wrote:
> > >
> > > It's useful for implementing EDT related tests (set tstamp, run the
> > > test, see how the tstamp is changed or observe some other parameter).
> > >
> > > Note that bpf_ktime_get_ns() helper is using monotonic clock, so for
> > > the BPF programs that compare tstamp against it, tstamp should be
> > > derived from clock_gettime(CLOCK_MONOTONIC, ...).
> > >
> > > Signed-off-by: Stanislav Fomichev <sdf@...gle.com>
> > > ---
> > >  net/bpf/test_run.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > >
> > > diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> > > index 1153bbcdff72..0be4497cb832 100644
> > > --- a/net/bpf/test_run.c
> > > +++ b/net/bpf/test_run.c
> > > @@ -218,10 +218,18 @@ static int convert___skb_to_skb(struct sk_buff *skb, struct __sk_buff *__skb)
> > >
> > >         if (!range_is_zero(__skb, offsetof(struct __sk_buff, cb) +
> > >                            FIELD_SIZEOF(struct __sk_buff, cb),
> > > +                          offsetof(struct __sk_buff, tstamp)))
> > > +               return -EINVAL;
> > > +
> > > +       /* tstamp is allowed */
> > > +
> > > +       if (!range_is_zero(__skb, offsetof(struct __sk_buff, tstamp) +
> > > +                          FIELD_SIZEOF(struct __sk_buff, tstamp),
> >
> > with no context on this particular change whatsoever: isn't this the
> > same as offsetofend(struct __sk_buff, tstamp)? Same above for cb.
> >
> > Overall, this seems like the 4th similar check, would it make sense to
> > add a static array of ranges we want to check for zeros and just loop
> > over it?..
> 
> I wouldn't bother, but offsetofend() is a good suggestion that
> can be done in a followup.
> 
> Applied both patches. Thanks
Thanks. I'll follow up with offsetofend, sounds like a good suggestion
that can eliminate a bit of copy paste.