linux-kernel - Re: [PATCH RFC bpf-next 1/4] bpf: add struct largest member size in func model

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: <b6878f60a62c4c6b4b7daa2272a18280e8fc362b.camel@gmail.com>
Date: Mon, 28 Apr 2025 00:11:46 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Xu Kuohai <xukuohai@...weicloud.com>, Alexis Lothoré
	 <alexis.lothore@...tlin.com>, Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: 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>,
 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>,  Puranjay Mohan
 <puranjay@...nel.org>, Catalin Marinas <catalin.marinas@....com>, Will
 Deacon <will@...nel.org>,  Mykola Lysenko	 <mykolal@...com>, Shuah Khan
 <shuah@...nel.org>, Maxime Coquelin	 <mcoquelin.stm32@...il.com>, Alexandre
 Torgue <alexandre.torgue@...s.st.com>,  Florent Revest
 <revest@...omium.org>, Bastien Curutchet <bastien.curutchet@...tlin.com>, 
	ebpf@...uxfoundation.org, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, 
	bpf@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kselftest@...r.kernel.org, 
	linux-stm32@...md-mailman.stormreply.com
Subject: Re: [PATCH RFC bpf-next 1/4] bpf: add struct largest member size in
 func model

On Fri, 2025-04-25 at 17:23 +0800, Xu Kuohai wrote:

[...]

> For the two questions you mentioned, I’m not sure if we can access DWARF attributes
> at runtime. As for adding parameter locations to BTF at building time, I think it
> means we would need to record CPU-related register info in BTF, which I don’t think
> is a good idea.

Another option would be for pahole to check if function parameter
DW_AT_locaction is placed in accordance with ABI.
These flags can be recorded in a dedicated section or smth like this.
Having said that, DW_AT_locaction seem to be not very reliable.
E.g. for bpf_testmod.ko generated by clang 19.1.7 I don't see
DW_AT_locaction specified for parameters a, b, c.