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: <CAMj1kXEs5=VRi_rJwgHUrQWos-27PBbr3c4fYnmkV8Ahi8HZgw@mail.gmail.com>
Date: Sat, 11 Oct 2025 07:48:04 -0700
From: Ard Biesheuvel <ardb@...nel.org>
To: Huacai Chen <chenhuacai@...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, 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.