On 2/27/25 17:24, Alexei Starovoitov wrote: > 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. Hi Alexei, this slipped off my radar due to other priorities recently but I should be able to get to it in the upcoming weeks. As you say, it shouldn't be much work so I hope to get back with a v2 soon. Thanks for poking me :) Viktor > > 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. >
