On Tue, Jun 30, 2020 at 11:23:07AM -0700, Andrii Nakryiko wrote: > On Mon, Jun 29, 2020 at 5:28 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Thu, Jun 18, 2020 at 3:33 PM Andrii Nakryiko > > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > + * > > > > + * int bpf_copy_from_user(void *dst, u32 size, const void *user_ptr) > > > > > > Can we also add bpf_copy_str_from_user (or bpf_copy_from_user_str, > > > whichever makes more sense) as well? > > > > Those would have to wait. I think strings need better long term design. > > That would be separate patches. > > I agree that it would be nice to have better support for strings, long > term, but that's beside the point. > > I think bpf_copy_from_user_str() is a must have right now as a > sleepable counterpart to bpf_probe_read_user_str(), just like > bpf_copy_from_user() is a sleepable variant of bpf_probe_read_user(). > Look at progs/strobemeta.h, it does bpf_probe_read_user_str() to get > user-space zero-terminated strings. It's well defined interface and > behavior. There is nothing extra needed beyond a sleepable variant of > bpf_probe_read_user_str() to allow Strobemeta reliably fetch data from > user-space from inside a sleepable BPF program. short answer: may be. long answer: I'm not sure that bpf_probe_read_user_str() is such a great interface. Copy pasting something just because it exists and already known is imo not the best approach. I believe KP is thinking about string chunking logic to be able to pass many null terminated strings from bpf prog to user space. envvars is such example. It's one giant array of strings separated by zeros. The semantics of bpf_probe_read_user_str() may or may not be a good fit. strobemeta is 'cheating' with strings by doing max bound on all of them. For tracing applications like strobemeta it's ok, but for lsm it's not. Hence I'd like to see an api that solves lsm case along with strobemeta case.
