netdev - Re: [RFC bpf-next v2 1/9] net: introduce __init_skb{,_data,

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]

Date:   Thu, 21 Mar 2019 09:58:44 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Stanislav Fomichev <sdf@...gle.com>,
        Network Development <netdev@...r.kernel.org>,
        bpf@...r.kernel.org, David Miller <davem@...emloft.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        simon.horman@...ronome.com, Willem de Bruijn <willemb@...gle.com>,
        Petar Penkov <peterpenkov96@...il.com>
Subject: Re: [RFC bpf-next v2 1/9] net: introduce __init_skb{,_data,_shinfo} helpers

On Thu, Mar 21, 2019 at 12:45 AM Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
>
> On 03/20/2019 08:39 PM, Alexei Starovoitov wrote:
>
> > I think you need to convince Dave and Eric that
> > above surgery is necessary to do the hack in patch 6 with
> > +static DEFINE_PER_CPU(struct sk_buff, bpf_flow_skb);
> >
>
> Yes, this is a huge code churn.

It touches a lot of lines. But it deduplicates logic that might become
out of sync if we don't do that now.

> Honestly I believe we are going too far in this series.
>
> > I think the better option it to introduce new prog type that works
> > without skb. I think it can be pretty close to shape and form to xdp.
> >

That's an interesting alternative. The existing sample dissector
does not access any skb fields aside from vlan. The interface could
be superseded with one that has a more constrained context, like xdp.

When parsing for headlen in the device driver rx path, a program could
conceivably in the same pass also compute an rxhash in case the
device did not supply an L4 one. And perhaps some hash (the same?)
to speed up GRO flow lookup. This would require a few extra fields in
bpf_flow_keys.