linux-kernel - Re: [REGRESSION] module BTF validation failure (Error -22) on next

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: <00b4f995-7105-499e-93b0-5e32d54948aa@oracle.com>
Date: Thu, 16 Jan 2025 09:51:44 +0000
From: Alan Maguire <alan.maguire@...cle.com>
To: Cong Wang <xiyou.wangcong@...il.com>
Cc: Uros Bizjak <ubizjak@...il.com>, Laura Nao <laura.nao@...labora.com>,
        bpf@...r.kernel.org, chrome-platform@...ts.linux.dev,
        kernel@...labora.com, linux-kernel@...r.kernel.org,
        regressions@...ts.linux.dev,
        Stephen Brennan <stephen.s.brennan@...cle.com>,
        "dwarves@...r.kernel.org" <dwarves@...r.kernel.org>
Subject: Re: [REGRESSION] module BTF validation failure (Error -22) on next

On 15/01/2025 17:38, Cong Wang wrote:
> On Mon, Dec 16, 2024 at 03:19:01PM +0000, Alan Maguire wrote:
>> Seems like there's a few approaches we can take in fixing this:
>>
>> 1. designate "__pcpu_" prefix as a variable prefix to filter out. This
>> resolves the immediate problem but is too narrowly focused IMO and we
>> may end up playing whack-a-mole with other dummy variable prefixes.
>> 2. resurrect ELF section variable information fully; i.e. record a list
>> of variables per ELF section (or at least per ELF section we care
>> about). If variable is not on the list for the ELF section, do not
>> encode it.
>> 3. midway between the two; for the 0 address case specifically, verify
>> that the variable name really _is_ in the associated ELF section. No
>> need to create a local ELF table variable representation, we could just
>> walk the table in the case of the 0 addresses.
>>
>> Diff for approach 3 is as follows
> 
> Hi Alan,
> 
> Thanks for your detailed analysis.
> 
> Is your patch formally submitted and merged? A quick code search with
> variable_in_sec() tells me no, but I could very easily miss things here,
> hence I am asking you. :)

hi Cong, I submitted the patch here:

https://lore.kernel.org/dwarves/20241217103629.2383809-1-alan.maguire@oracle.com/

..but it looks like it hasn't landed officially yet, apologies about
that. Would you mind testing the master branch of dwarves with the patch
applied to confirm the problem is fixed? It worked at my end but would
be great to confirm it fixes the issue on your side too. Thanks!

Alan