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-H41m96fvEWG5NqAE=tykPjyzt=50CseJDeCqdG-c_WMrQ@mail.gmail.com>
Date: Sat, 11 Oct 2025 15:42:56 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc: Ard Biesheuvel <ardb@...nel.org>, Josh Poimboeuf <jpoimboe@...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
Subject: Re: [PATCH v2] efistub: Only link libstub to final vmlinux

On Sat, Oct 11, 2025 at 3:29 PM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
>
> On 2025/10/11 上午11:40, Ard Biesheuvel wrote:
> > On Fri, 10 Oct 2025 at 19:54, Huacai Chen <chenhuacai@...nel.org> wrote:
> >>
> >> On Sat, Oct 11, 2025 at 9:13 AM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
> >>>
> >>> On 2025/10/11 上午12:25, Ard Biesheuvel wrote:
> >>> ...
> >>>> Why do we need both (1) and (2)?
> >>>
> >>> Not both, either (1) or (2).
> >>> Which one do you prefer? Or any other suggestions?
> >>>
> >>> Taking all of the considerations in balance, we should decide
> >>> what is the proper way.
> >> As a summary, there are three methods:
> >> (1) Only link libstub with vmlinux.o during the final vmlinux link.
> >> (2) Remove the attribute __noreturn for real_kernel_entry() and add while (1).
> >> (3) Ignore "__efistub_" prefix in objtool.
> >>
> >> Josh prefers method (1), I prefer method (3) but also accept method
> >> (1) if it is not only specific to loongarch.
> >>
> >
> > This is a false positive warning in objtool, which complains about a
> > function that falls through, even though that can never happen in
> > reality.
> >
> > To me, it is not acceptable to modify how vmlinux.o is constructed
> > also for other architectures, in order to hide some of its constituent
> > parts from objtool, which do not use objtool to begin with.
> >
> >
> > If you are not willing to fix objtool, I suggest fixing the loongarch
> > code like this:
>
> Thank you.
>
> > --- a/drivers/firmware/efi/libstub/loongarch.c
> > +++ b/drivers/firmware/efi/libstub/loongarch.c
> > @@ -10,7 +10,7 @@
> >   #include "efistub.h"
> >   #include "loongarch-stub.h"
> >
> > -typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline,
> > +typedef void (*kernel_entry_t)(bool efi, unsigned long cmdline,
> >                                            unsigned long systab);
> >
> >   efi_status_t check_platform_features(void)
> > @@ -81,4 +81,6 @@
> >
> >          real_kernel_entry(true, (unsigned long)cmdline_ptr,
> >                            (unsigned long)efi_system_table);
> > +
> > +       return EFI_LOAD_ERROR;
> >   }
>
> I tested the above changes, the falls through objtool warning can
> be fixed because efi_boot_kernel() ends with a return instruction,
> I think this is reasonable.
>
> efi_boot_kernel() has a return value, there are "return status" in
> other parts of efi_boot_kernel(), it should also return at the end
> of efi_boot_kernel() in theory, although we should never get here.
>
> If there are more comments, please let me know.
I still don't want LoongArch to be a special case, which means
efi_boot_kernel() in fdt.c, jump_kernel_func in riscv.c and
enter_kernel in arm64.c should also be modified.

Huacai

>
> Thanks,
> Tiezhu
>