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-H7HN128du-b1Rk_9qbYBq7gMSwo0s31909N4pTou6wzew@mail.gmail.com>
Date: Sat, 11 Oct 2025 23:01:28 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Tiezhu Yang <yangtiezhu@...ngson.cn>, 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 10:48 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> On Sat, 11 Oct 2025 at 00:43, Huacai Chen <chenhuacai@...nel.org> wrote:
> >
> > 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.
> >
>
> You have made LoongArch a special case by adding objtool support,
> which  arm64 and RISC-V do not have.
>
> So NAK to changing arm64 and RISC-V as well.
Hmmm, I want to know whether this problem is an objtool issue or an
efistub issue in essence. If it is an objtool issue, we should fix
objtool and don't touch efistub. If it is an efistub issue, then we
should modify efistub (but not specific to LoongArch, when RISC-V and
ARM64 add objtool they will meet the same issue).

Huacai