[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b5f6cd0-2b5f-4687-ad43-73a7be8fbfd0@redhat.com>
Date: Wed, 28 May 2025 14:47:56 +0200
From: Jerome Marchand <jmarchan@...hat.com>
To: Eduard Zingerman <eddyz87@...il.com>
Cc: bpf@...r.kernel.org, Martin KaFai Lau <martin.lau@...ux.dev>,
Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>, linux-kernel@...r.kernel.org,
Yonghong Song <yonghong.song@...ux.dev>
Subject: Re: [PATCH] bpf: Specify access type of bpf_sysctl_get_name args
On 27/05/2025 23:39, Eduard Zingerman wrote:
> "Jerome Marchand" <jmarchan@...hat.com> 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@...hat.com>
>> ---
>
> 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).
>
Powered by blists - more mailing lists