Apologies for the resend due to an incorrect configuration in my mail client.
Thanks for your comment!
On Dec 23, 2025, at 03:29, Amery Hung ameryhung@gmail.com wrote:
Perhaps you are conflating one of your proposals here? This is fine currently. ARG_PTR_TO_MEM without any annotation is viewed as BPF_READ so passing a read-only buffer should work.
Actually, that is not the case. I tested this again, and ARG_PTR_TO_MEM without MEM_RDONLY does reject read-only buffers. You can reproduce this behavior with test_d_path_check_rdonly_mem in selftests by removing its arg2’s MEM_WRITE tag.
I think it is better to make the MEM_WRITE, MEM_RDONLY annotation explicit and check it in the verifier.
Flipping the default MEM_RDONLY semantic to MEM_WRITE does not prevent a similar bug in the future when we have helpers/optimizations/checks rely on an implicit semantic.
The current default semantic is in an inconsistent state: it implies neither MEM_RDONLY nor MEM_WRITE. A naked ARG_PTR_TO_MEM rejects read-only buffers, yet tells the verifier that the helper does not modify the memory.
I see two ways to resolve this ambiguity: 1) Enforce explicit memory access tags (disallow naked ARG_PTR_TO_MEM) as I proposed eariler; or 2) Change ARG_PTR_TO_MEM semantics to behave exactly like ARG_PTR_TO_MEM | MEM_RDONLY.
I would appreciate your thoughts on this. :)
Thanks, Zesen Liu