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: <CAEf4Bzb+ZjwA-Jxd4fD6nkYnKGAjOt=2Pz-4GNWBbxtNZJ85UQ@mail.gmail.com>
Date:   Tue, 15 Oct 2019 16:14:51 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Stanislav Fomichev <sdf@...gle.com>
Cc:     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 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?..

>                            sizeof(struct __sk_buff)))
>                 return -EINVAL;
>
>         skb->priority = __skb->priority;
> +       skb->tstamp = __skb->tstamp;
>         memcpy(&cb->data, __skb->cb, QDISC_CB_PRIV_LEN);
>
>         return 0;
> @@ -235,6 +243,7 @@ static void convert_skb_to___skb(struct sk_buff *skb, struct __sk_buff *__skb)
>                 return;
>
>         __skb->priority = skb->priority;
> +       __skb->tstamp = skb->tstamp;
>         memcpy(__skb->cb, &cb->data, QDISC_CB_PRIV_LEN);
>  }
>
> --
> 2.23.0.700.g56cf767bdb-goog
>