linux-kernel - Re: [PATCH v2] efistub: Only link libstub to final vmlinux

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: <CAAhV-H4fHBuRpDEDQrExApgnREJaT8JWUJ2700bEPFxDqToi2w@mail.gmail.com>
Date: Sun, 23 Nov 2025 10:29:02 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc: Will Deacon <will@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Paul Walmsley <pjw@...nel.org>, 
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, 
	"Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>, Ard Biesheuvel <ardb@...nel.org>, 
	loongarch@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, 
	linux-riscv@...ts.infradead.org, linux-efi@...r.kernel.org, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Nathan Chancellor <nathan@...nel.org>
Subject: Re: [PATCH v2] efistub: Only link libstub to final vmlinux

On Sat, Nov 22, 2025 at 7:04 PM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
>
> Cc: Nathan Chancellor <nathan@...nel.org>
>
> Hi all,
>
> On 11/21/25 22:36, Huacai Chen wrote:
> > On Mon, Nov 17, 2025 at 7:33 PM Will Deacon <will@...nel.org> wrote:
> >>
> >> On Sat, Nov 15, 2025 at 11:16:42AM +0800, Huacai Chen wrote:
> >>> On Wed, Nov 12, 2025 at 2:00 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> >>>>
> >>>> On Mon, Nov 10, 2025 at 03:00:00PM +0800, Huacai Chen wrote:
> >>>>> On Mon, Nov 10, 2025 at 9:19 AM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
> >>>>>> If I understand correctly, I should modify this patch to remove the
> >>>>>> changes of arm and riscv for now, do the changes only when there is
> >>>>>> a real problem or requirement some day, right? If no more comments,
> >>>>>> I will send v3 later.
> >>>>>
> >>>>> Now everyone involved agrees that the efistub code is correct, so the
> >>>>> proper solution is to fix the compiler.
> >>>>
> >>>> Hm?  I don't see how it's a compiler bug.  It's really just an objtool
> >>>> limitation.
> >>>>
> >>>>> Changing efistub code and changing objtool (ignore __efistub prefix)
> >>>>> are both workarounds, but I think changing objtool is a little more
> >>>>> reasonable. Maybe Josh has different ideas?
> >>>>
> >>>> I thought the conversation had converged on what Tiezhu mentioned above,
> >>>> which is to skip objtool on libstub for loongarch, but leave the other
> >>>> arches alone.  That way objtool behavior is consistent between loongarch
> >>>> and x86, and objtool doesn't need to ignore any prefixes.
> >>>>
> >>>> So basically, the v2 patch minus the arm64/riscv changes.
> >>>
> >>> Hi, ARM64 and RISC-V maintainers,
> >>>
> >>> Would you mind that this patch modifies the three architectures
> >>> together (they are exactly the same style now)?
> >>>
> >>> Madhavan is the author of ARM64's objtool, I think your opinion is
> >>> also very important.
> >>
> >> arm64 doesn't (yet) use objtool.
> >>
> >> I defer to Ard on anything relating to the arm64 efistub. Reading the
> >> start of this thread, it doesn't look like he's convinced and I'm not
> >> surprised if it's purely an issue with objtool.
> > OK, I know, but I have a concern.
> >
> > Ard said that he is reluctant to make changes to accommodate a flawed
> > build time tool and there may be regression risk.
> >
> > So, I'm also reluctant and don't want LoongArch to meet regression
> > risk. If one day LoongArch has a regression, we probably need another
> > workaround to "fix" this workaround. But if these three architectures
> > change in the same way, we may have a chance to solve some fundamental
> > problems...
>
> IIUC, Josh do not like to ignore these EFISTUB functions in
> validate_branch() of objtool, Huacai do not like to only link
> libstub to vmlinux only for LoongArch.
>
> It seems that there is only one way to fix or workaround this
> problem, remove the attribute __noreturn for real_kernel_entry()
> and then make efi_boot_kernel() ends with a return instruction [1]
> or an unconditional jump instruction [2] that only touches
> drivers/firmware/efi/libstub/loongarch.c.
>
> Since this is a issue only for LoongArch by now, what do you
> think of this minimal change only for LoongArch libstub code?
> Using "return EFI_LOAD_ERROR" [1] or "while (1)" [2]?
>
> Maybe this is the simple and direct way for this special issue
> only on LoongArch so far. If not, any other suggestions?
>
> On the other hand, is it possible to add KBUILD_VMLINUX_LIBS_FINAL
> and then use it only for LoongArch first [3]? Any potential risks?
>
> What is the next step?
Is it possible to improve objtool that can handle indirect __noreturn functions?
Is it possible to improve objtool that can handle
OBJECT_FILES_NON_STANDARD event LTO is enabled?
Is it possible to improve objtool that only ignore __efistub prefix
for LoongArch?


Huacai

>
> [1]
> https://lore.kernel.org/loongarch/CAMj1kXH-rK0bRyHXdJ-crAyMyvJHApH0WR7_8Qd8vrSPBLK+yg@mail.gmail.com/
> [2]
> https://lore.kernel.org/loongarch/20250826064631.9617-2-yangtiezhu@loongson.cn/
> [3] https://lore.kernel.org/loongarch/20251122000101.GA1996391@ax162/
>
> Thanks,
> Tiezhu
>