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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 21 Aug 2020 12:22:46 +0200 From: Jakub Sitnicki <jakub@...udflare.com> To: Alexei Starovoitov <alexei.starovoitov@...il.com> Cc: bpf <bpf@...r.kernel.org>, Network Development <netdev@...r.kernel.org>, kernel-team <kernel-team@...udflare.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Andrii Nakryiko <andriin@...com>, Lorenz Bauer <lmb@...udflare.com>, Marek Majkowski <marek@...udflare.com>, Martin KaFai Lau <kafai@...com>, Yonghong Song <yhs@...com> Subject: Re: BPF sk_lookup v5 - TCP SYN and UDP 0-len flood benchmarks On Fri, Aug 21, 2020 at 12:18 AM CEST, Alexei Starovoitov wrote: > On Thu, Aug 20, 2020 at 3:29 AM Jakub Sitnicki <jakub@...udflare.com> wrote: >> On Tue, Aug 18, 2020 at 08:19 PM CEST, Alexei Starovoitov wrote: [...] >> > Long term we should probably stop doing *_kern style of ctx passing >> > into bpf progs. >> > We have BTF, CO-RE and freplace now. This old style of memset *_kern and manual >> > ctx conversion has performance implications and annoying copy-paste of ctx >> > conversion routines. >> > For this particular case instead of introducing udp4_lookup_run_bpf() >> > and copying registers into stack we could have used freplace of >> > udp4_lib_lookup2. >> > More verifier work needed, of course. >> > My main point that existing approach "lets prep args for bpf prog to >> > run" that is used >> > pretty much in every bpf hook is no longer necessary. >> >> Andrii has also suggested leveraging BTF [0], but to expose the *_kern >> struct directly to BPF prog instead of emitting ctx access instructions. >> >> What I'm curious about is if we get rid of prepping args and ctx >> conversion, then how do we limit what memory BPF prog can access? >> >> Say, I'm passing a struct sock * to my BPF prog. If it's not a tracing >> prog, then I don't want it to have access to everything that is >> reachable from struct sock *. This is where this approach currently >> breaks down for me. > > Why do you want to limit it? > Time after time we keep extending structs in uapi/bpf.h because new > use cases are coming up. Just let the prog access everything. I guess I wasn't thinking big enough :-)
Powered by blists - more mailing lists