netdev - Re: [PATCH bpf-next] bpf: allow BPF read access to qdisc pkt

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 for Android: free password hash cracker in your pocket

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

Date:   Sat, 1 Dec 2018 16:02:48 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     liu.song.a23@...il.com,
        Network Development <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Petar Penkov <peterpenkov96@...il.com>,
        Vlad Dumitrescu <vladum@...gle.com>,
        Petar Penkov <ppenkov@...gle.com>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH bpf-next] bpf: allow BPF read access to qdisc pkt_len

On Fri, Nov 30, 2018 at 7:41 PM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> On 12/01/2018 12:42 AM, Willem de Bruijn wrote:
> > On Fri, Nov 30, 2018 at 5:48 PM Song Liu <liu.song.a23@...il.com> wrote:
> >>
> >> On Fri, Nov 30, 2018 at 12:09 PM Willem de Bruijn
> >> <willemdebruijn.kernel@...il.com> wrote:
> >>>
> >>> From: Petar Penkov <ppenkov@...gle.com>
> >>>
> >>> The pkt_len field in qdisc_skb_cb stores the skb length as it will
> >>> appear on the wire after segmentation. For byte accounting, this value
> >>> is more accurate than skb->len. It is computed on entry to the TC
> >>> layer, so only valid there.
> >>>
> >>> Allow read access to this field from BPF tc classifier and action
> >>> programs. The implementation is analogous to tc_classid, aside from
> >>> restricting to read access.
> >>>
> >>> Signed-off-by: Petar Penkov <ppenkov@...gle.com>
> >>> Signed-off-by: Vlad Dumitrescu <vladum@...gle.com>
> >>> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
> >>> ---
> >>>  include/uapi/linux/bpf.h                    |  1 +
> >>>  net/core/filter.c                           | 16 +++++++++++
> >>>  tools/include/uapi/linux/bpf.h              |  1 +
> >>>  tools/testing/selftests/bpf/test_verifier.c | 32 +++++++++++++++++++++
> >>>  4 files changed, 50 insertions(+)
> >>
> >> Please split this into 3 patches:
> >> 1 for include/uapi/linux/bpf.h and filter.c
> >> 1 for tools/include/uapi/linux/bpf.h
> >> 1 for tools/testing/selftests/bpf/test_verifier.c
> >>
> >> Other than this
> >> Acked-by: Song Liu <songliubraving@...com>
> >
> > Thanks for the fast review.
> >
> > I'm happy to resend in three parts, of course, but am curious: what is
> > the rationale for splitting this up?
> >
> > This patch follows the process for commit  f11216b24219 ("bpf: add
> > skb->tstamp r/w access from tc clsact and cg skb progs"), which went
> > in as a single patch just last week.
>
> Yeah, I think it's fine as is, one small thing I'm wondering though is
> given that we now would have both 'skb->len' and 'skb->pkt_len', would
> it be more intuitive for a BPF program developer to distinguish the two
> by having the latter named e.g. 'skb->wire_len' so it's slightly more
> obvious that it's including header size at post-segmentation?

Yes, I actually had considered qdisc_pkt_len to drive home the point
that this is derived from, and thus defined by, qdisc_pkt_len_init. But
wire_len is a much more intuitive description. I'll send a v2. Thanks!