Re: [PATCH bpf-next 1/2] bpf: Add kfuncs for read-only string operations

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

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@gmail.com> wrote:
>
> On Thu, Oct 3, 2024 at 12:37 PM Viktor Malik <vmalik@redhat.com> 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.