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: <Z1F58qzclMgeEMcC@krava>
Date: Thu, 5 Dec 2024 11:01:22 +0100
From: Jiri Olsa <olsajiri@...il.com>
To: Laura Nao <laura.nao@...labora.com>
Cc: alan.maguire@...cle.com, bpf@...r.kernel.org,
	chrome-platform@...ts.linux.dev, kernel@...labora.com,
	linux-kernel@...r.kernel.org, regressions@...ts.linux.dev
Subject: Re: [REGRESSION] module BTF validation failure (Error -22) on next

On Wed, Nov 13, 2024 at 10:37:03AM +0100, Laura Nao wrote:
> Hi Alan,
> 
> On 11/7/24 16:05, Alan Maguire wrote:
> > Thanks for the report! Judging from the config, you're seeing this with
> > pahole v1.24. I have seen issues like this in the past where during a
> > kernel build, module BTF has been built against vmlinux BTF, and then
> > something later re-triggers vmlinux BTF generation. If that re-triggered
> > vmlinux BTF does not use the same type ids for types, this can result in
> > mismatch errors as above since modules are referring to out-of-date type
> > ids in vmlinux. That's just a preliminary guess though, we'll
> > need more info to help get to the bottom of this.
> > 
> > A few suggestions to help debug this:
> > 
> > - if you have build logs, check BTF generation of vmlinux. Did it in
> > fact happen twice perhaps? Even better if, if kernel CI saves logs, feel
> > free to send a pointer and I'll take a look.
> 
> Thanks for the pointers!
> 
> From what I can tell in the logs, the BTF generation of vmlinux only 
> occurred once. The automated build process in KernelCI generally involves 
> building the kernel first, followed by the modules and other artifacts 
> (such as the kselftest archive). 
> The full build log can be downloaded by selecting 'build_log' from 
> the dropdown menu at the top of this page:
> 
> https://kernelci-api.westus3.cloudapp.azure.com/viewer?node_id=6732f41d58937056c61734ab
> 
> I do see some warnings reported in the logs though:
> 
> WARN: resolve_btfids: unresolved symbol bpf_lsm_task_getsecid_obj
> WARN: resolve_btfids: unresolved symbol bpf_lsm_current_getsecid_subj

hi,
this is fixed in bpf/master already:
  8618f5ffba4d bpf, lsm: Remove getlsmprop hooks BTF IDs

I can't reproduce this as well, will check the logs you posted

jirka

> 
> > - can you post the vmlinux (stripped of DWARF data if possible to limit
> > size) and one of the failing modules somewhere so we can analyze?
> > - Failing that,
> > bpftool btf dump file /path/2/vmlinux_from_build > vmlinux.raw
> > and upload of the vmlinux.raw and one of the failing module .kos would help.
> > 
> 
> Currently, KernelCI only retains the bzImage, not the vmlinux binary. The 
> bzImage can be downloaded from the same link mentioned above by selecting 
> 'kernel' from the dropdown menu (modules can also be downloaded the same
> way). I’ll try to replicate the build on my end and share the vmlinux 
> with DWARF data stripped for convenience.
> 
> Thanks,
> 
> Laura
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ