On Tue, Apr 4, 2023 at 2:06 PM Daniel Rosenberg <drosen@xxxxxxxxxx> wrote: > > 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'm pretty sure we can make bpf_dynptr_data() support readonly dynptrs. Should be easy to add in the verifier. But could you pseudo code what you're trying to do first? Do you expect bpf prog to see both ro and rw dynptrs on input? And you want bpf prog to use bpf_dynptr_data() to access these buffers wrapped as dynptr-s? The string manipulation questions muddy the picture here. If bpf progs deals with file system block data why strings? Is that a separate set of bpf prog hooks that receive strings on input wrapped as dynptrs? What are those strings? file path? We need more info to help you design the interface, so it's easy to use from bpf prog pov.
