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
| ||
|
Message-ID: <20190201210640.yjnb4jriekec3mcs@ast-mbp> Date: Fri, 1 Feb 2019 13:06:42 -0800 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: Peter Oskolkov <posk@...gle.com> Cc: Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org, Peter Oskolkov <posk.devel@...il.com>, 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 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.
Powered by blists - more mailing lists