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
| ||
|
Date: Wed, 18 May 2022 14:48:30 +0530 From: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com> To: Baoquan He <bhe@...hat.com>, Michael Ellerman <mpe@...erman.id.au> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>, kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org Subject: Re: [PATCH] kexec_file: Drop pr_err in weak implementations of arch_kexec_apply_relocations[_add] Baoquan He wrote: > On 05/18/22 at 12:26pm, Michael Ellerman wrote: >> >> It seems that recordmcount is not really maintained anymore now that x86 >> uses objtool? >> >> There've been several threads about fixing recordmcount, but none of >> them seem to have lead to a solution. >> >> These weak symbol vs recordmcount problems have been worked around going >> back as far as 2020: > > It gives me feeling that llvm or recordmcount should make adjustment, > but not innocent kernel code, if there are a lot of places reported. > I am curious how llvm or recordmcount dev respond to this. As Michael stated, this is not just llvm - binutils has also adopted the same and "unused" section symbols are being dropped. For recordmcount, there were a few threads and approaches that have been tried: - https://patchwork.ozlabs.org/project/linuxppc-dev/patch/cd0f6bdfdf1ee096fb2c07e7b38940921b8e9118.1637764848.git.christophe.leroy@csgroup.eu/ - https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=297434&state=* Objtool has picked up a more appropriate fix for this recently, and long-term, we would like to move to using objtool for ftrace purposes: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/tools/objtool/elf.c?id=4abff6d48dbcea8200c7ea35ba70c242d128ebf3 While that is being pursued, we want to unbreak some of the CI and users who are hitting this. - Naveen
Powered by blists - more mailing lists