linux-kernel - Re: [PATCH] bpf: Specify access type of bpf_sysctl_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c97284b4-cac8-4dcc-991b-d535694f31c5@redhat.com>
Date: Thu, 29 May 2025 13:35:55 +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 28/05/2025 18:41, Eduard Zingerman wrote:
> Jerome Marchand <jmarchan@...hat.com> writes:
> 
> [...]
> 
>>> 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.
> 
> Yes, something like that, taking an unsafe action based on content of
> the buffer after the helper call.

Alright, I'll do that.

> 
>> 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.
> 
> That would be interesting, I think.
> Depends on how much time you need to write such a test.

I might think about it, but ATM, I just don't have time to do that. If 
someone is interested in implementing it, be my guest.

> 
> [...]
>