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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQKUV2TEDdekj0xApPqm6q0kCK-SvvpT5=80YQcsfuvXFw@mail.gmail.com>
Date:   Tue, 15 Oct 2019 16:26:28 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     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 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