Viktor, Are you still planning to work on string kfuncs ? I think we more or less converged on requirements. So only a small matter of programming is left ? :) If you're busy with other things we can take over. On Wed, Oct 9, 2024 at 7:03 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, Oct 3, 2024 at 12:37 PM Viktor Malik <vmalik@xxxxxxxxxx> wrote: > > > > Anyways, it seems to me that both the bounded and the unbounded versions > > have their place. Would it be ok with you to open-code just the > > unbounded ones and call in-kernel implementations for the bounded ones? > > Right. Open coding unbounded ones is not a lot of code. > We can copy paste from arch/x86/boot/string.c and replace > pointer deref with __get_kernel_nofault(). > No need to be fancy. > > The bounded ones should call into in-kernel bits that are > optimized in asm. > > Documenting the difference in performance between bounded vs unbounded > should be part of the patch. > > > Also, just out of curiosity, what are the ways to create/obtain strings > > of unbounded length in BPF programs? Arguments of BTF-enabled program > > types (like fentry)? Any other examples? Because IIUC, when you read > > strings from kernel/userspace memory using bpf_probe_read_str, you > > always need to specify the size. > > The main use case is argv/env processing in bpf-lsm programs. > These strings are nul terminated and can be very large. > Attackers use multi megabyte env vars to hide things. > > Folks push them into ringbuf and strstr() in user space as a workaround. > Unbounded bpf_strstr() kfunc would be handy.
