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@xxxxxxxxxxxxxx> 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 :-)
