linux-kernel - Re: [PATCH bpf-next v9 4/9] bpf: Add syscall common attributes support for prog

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <097f4aa3-dfa6-4847-8395-8108323b020f@linux.dev>
Date: Fri, 6 Feb 2026 10:45:17 +0800
From: Leon Hwang <leon.hwang@...ux.dev>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: bpf@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
 Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
 Shuah Khan <shuah@...nel.org>, Christian Brauner <brauner@...nel.org>,
 Seth Forshee <sforshee@...nel.org>, Yuichiro Tsuji <yuichtsu@...zon.com>,
 Andrey Albershteyn <aalbersh@...hat.com>,
 Willem de Bruijn <willemb@...gle.com>, Jason Xing
 <kerneljasonxing@...il.com>, Tao Chen <chen.dylane@...ux.dev>,
 Mykyta Yatsenko <yatsenko@...a.com>,
 Kumar Kartikeya Dwivedi <memxor@...il.com>,
 Anton Protopopov <a.s.protopopov@...il.com>, Amery Hung
 <ameryhung@...il.com>, Rong Tao <rongtao@...tc.cn>,
 linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
 linux-kselftest@...r.kernel.org, kernel-patches-bot@...com
Subject: Re: [PATCH bpf-next v9 4/9] bpf: Add syscall common attributes
 support for prog_load



On 6/2/26 06:18, Andrii Nakryiko wrote:
> On Wed, Feb 4, 2026 at 7:42 PM Leon Hwang <leon.hwang@...ux.dev> wrote:

[...]

>>>> +
>>>> +       if (!attr->log_buf && attr_common->log_buf) {
>>>> +               attr->log_buf = attr_common->log_buf;
>>>> +               attr->log_size = attr_common->log_size;
>>>> +               attr->log_level = attr_common->log_level;
>>>
>>> why are we setting this? Do we still have code that can access
>>> attr->log_buf even though we pass attr_log everywhere? If yes, should
>>> we still have that "split brain" code?
>>>
>>
>> 'attr->log_buf' is accessed only in bpf_check().
> 
> bpf_check should be changed then, see below
> 
>>
>>> If we don't have this assignment, then I think we don't need to have
>>> bpf_prog_load-specific and btf_load-specific log_attr_init() helpers.
>>> They can be unified into generic log_attr_init, where for
>>> bpf_prog_load you'll pass offsetof(log_true_size) +
>>> attr->log_{buf,size,level}, and for btf_load you'll pass different
>>> offset of and btf-specific attr->btf_log*
>>>
>>> This helper will just be making decision whether to use common_attr's
>>> log fields or passed directly command-specific ones.
>>>
>>> Or what am I missing?
>>>
>>
>> If the log attributes differ, where should the effective
>> log_* values be stored?
>>
>> Should they live in struct bpf_common_attr, or should we extend
>> struct bpf_log_attr to carry them?
>>
>> Note that in v8, Alexei suggested struct bpf_log_attr only needs
>>   u32 offsetof_true_size;
>>   bpfptr_t uattr;
>>
>> so I’d like to clarify the intended direction here. Once that’s clear, a
>> single generic log_attr_init() should be sufficient to handle this.
>>
> 
> The intended direction is to have log buf/size/level in one place
> (after attr and common_attr validations), so we keep internal logic
> simple. Let's put all of that and log_true_size **pointer** (we don't
> have to much with offsetof, just calculate user addr for
> log_true_size, which just might be NULL) into bpf_log_attrs and teach
> all code to look and work *only* with that struct, ignoring anything
> log related from attr.
> 
It’s clear now.

I’ll follow this direction in the next revision and consolidate all
log-related fields (including the log_true_size pointer) into
bpf_log_attr, so that internal code relies solely on that struct.

Thanks,
Leon