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.
