linux-kernel - Re: Apply a1e2c031ec39 and e32683c6f7d2 to 5.15 and earlier

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: <2023103135-yesterday-exhaust-a621@gregkh>
Date:   Tue, 31 Oct 2023 13:54:57 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Nathan Chancellor <nathan@...nel.org>
Cc:     Sasha Levin <sashal@...nel.org>, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org
Subject: Re: Apply a1e2c031ec39 and e32683c6f7d2 to 5.15 and earlier

On Fri, Oct 27, 2023 at 09:01:44AM -0700, Nathan Chancellor wrote:
> Hi Greg and Sasha,
> 
> Please consider applying the following mbox files to their respective
> stable trees, which contains commit a1e2c031ec39 ("x86/mm: Simplify
> RESERVE_BRK()") and commit e32683c6f7d2 ("x86/mm: Fix RESERVE_BRK() for
> older binutils"). This resolves a link failure noticed in the Android
> trees due to a new diagnostic in ld.lld:
> 
> https://github.com/llvm/llvm-project/commit/1981b1b6b92f7579a30c9ed32dbdf3bc749c1b40
> 
>   ld.lld: error: relocation refers to a symbol in a discarded section: __brk_reservation_fn_dmi_alloc__
>   >>> defined in vmlinux.o
>   >>> referenced by ld-temp.o
>   >>>               vmlinux.o:(exit_amd_microcode.cfi_jt)
> 
>   ld.lld: error: relocation refers to a symbol in a discarded section: __brk_reservation_fn_early_pgt_alloc__
>   >>> defined in vmlinux.o
>   >>> referenced by ld-temp.o
>   >>>               vmlinux.o:(exit_amd_microcode.cfi_jt)
> 
> While I think this may be related to Android's downstream use of LTO and
> CFI, I see no reason that this could not happen without LTO due to
> RESERVE_BRK() prior to those upstream commits residing in the
> .discard.text section.
> 
> I confirmed they resolve the Android build problem and I did an
> ARCH=x86_64 defconfig build and boot test in QEMU and an allmodconfig
> build with GCC, which had no regressions.

All now queued up, thanks!  If only all stable submissions were sent to
us in such easy-to-consume-form :)

thanks,

greg k-h