netdev - Re: [PATCH bpf-next v6 2/5] bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push

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]

Date:   Fri, 1 Feb 2019 14:24:23 -0800
From:   Peter Oskolkov <posk.devel@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Peter Oskolkov <posk@...gle.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        netdev <netdev@...r.kernel.org>, David Ahern <dsahern@...il.com>,
        Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH bpf-next v6 2/5] bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap

On Fri, Feb 1, 2019 at 1:06 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Fri, Feb 01, 2019 at 09:22:26AM -0800, Peter Oskolkov wrote:
> > This patch implements BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
> > BPF helper. It enables BPF programs (specifically, BPF_PROG_TYPE_LWT_IN
> > and BPF_PROG_TYPE_LWT_XMIT prog types) to add IP encapsulation headers
> > to packets (e.g. IP/GRE, GUE, IPIP).
> >
> > This is useful when thousands of different short-lived flows should be
> > encapped, each with different and dynamically determined destination.
> > Although lwtunnels can be used in some of these scenarios, the ability
> > to dynamically generate encap headers adds more flexibility, e.g.
> > when routing depends on the state of the host (reflected in global bpf
> > maps).
> >
> > Note: a follow-up patch with deal with GSO-enabled packets, which
> > are currently rejected at encapping attempt.
> >
> > Signed-off-by: Peter Oskolkov <posk@...gle.com>
> ...
> > +int bpf_lwt_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len, bool ingress)
> > +{
> > +     struct iphdr *iph;
> > +     bool ipv4;
> > +     int err;
> > +
> > +     if (unlikely(len < sizeof(struct iphdr) || len > LWT_BPF_MAX_HEADROOM))
> > +             return -EINVAL;
> > +
> > +     /* GSO-enabled packets cannot be encapped at the moment. */
> > +     if (unlikely(skb_is_gso(skb)))
> > +             return -EINVAL;
>
> I don't understand why that's 'unlikely'.
> Both tx and rx are very likely to have gso skbs.
> Are you saying this feature will require user to disable gro/gso on a device?
> imo gso has to be supported from the start.

OK, I'll work on v7 with GSO support... :)

>