On 27/05/2025 23:39, Eduard Zingerman wrote:
"Jerome Marchand" <jmarchan@xxxxxxxxxx> writes:The second argument of bpf_sysctl_get_name() helper is a pointer to a buffer that is being written to. However that isn't specify in the prototype. Until commit 37cce22dbd51a ("bpf: verifier: Refactor helper access type tracking"), all helper accesses were considered as a possible write access by the verifier, so no big harm was done. However, since then, the verifier might make wrong asssumption about the content of that address which might lead it to make faulty optimizations (such as removing code that was wrongly labeled dead). This is what happens in test_sysctl selftest to the tests related to sysctl_get_name. Correctly mark the second argument of bpf_sysctl_get_name() as ARG_PTR_TO_UNINIT_MEM. Signed-off-by: Jerome Marchand <jmarchan@xxxxxxxxxx> ---Looks like we don't run bpf_sysctl_get_name tests on the CI. CI executes the following binaries: - test_progs{,-no_alu32,-cpuv4} - test_verifier - test_maps test_progs is what is actively developed. I agree with the reasoning behind this patch, however, could you please add a selftest demonstrating unsafe behaviour?
Do you mean to write a selftest that demonstrate the current unsafe behavior of the bpf_sysctl_get_name helper? I could write something similar as the failing test_sysctl cases.
I'm thinking that a more general test that would check that helpers don't access memory in a different way than advertised in their prototype would be more useful. But that's quite a different endeavor.
Regards, Jerome
You can use tools/testing/selftests/bpf/progs/verifier_and.c as an example of verifier test checking for specific log message. (framework also supports execution if __retval is specified, tests can be written in plain C as well, e.g. as in .../iters.c).
