On Mon, Apr 3, 2023 at 9:57 PM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > bpf_dynptr_slice(_rdwr) is basically the same as bpf_dynptr_data() and > bpf_dynptr_read() as far as fixed length of read/accessible memory > goes, so I don't think it gives you anything new, tbh. > It does in the case of a readonly dynptr. bpf_dynptr_read requires a buffer. bpf_dynptr_data rejects readonly dynptrs, and doesn't really provide a way for the verifier to know the resulting buffer is readonly. bpf_dynptr_slice handles read-only dynptrs, but requires a buffer which will be unused for local dynptrs. Verification fails if I try to pass it a null pointer and a nonzero buffer length. That means to gain read only access to a read only dynptr of size 255, I'd need to either copy it with dynptr read, or declare an initialized buffer of size 255 which will be unused in order to gain direct access to the dynptr data. > > I think we need something like bpf_dynptr_strncmp(), which would take > two dynptrs, one for each string you'd like to compare. > > But in general, when you say "I need to access strings and blocks of > data " above, what exact operations do you need to do on them? strncmp > is one of them, anything else? > For blocks of data, probably memcmp. The upcoming dynptr apis should make editing specific parts easier. Might want a memmove style command at some point? For context, fuse-bpf allows intercepting FUSE_READ and editing the data before it's passed along. Or at least it will ;) The upcoming dynptr APIS you mentioned should handle most things there.
