linux-kernel - Re: [External] Re: [PATCH 3/3] efistub: fix missed the initialization of gp

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: <CAMj1kXFE_G5-od5kbOiU_4D7dwjksdrMTofHfYsLkjFtZDz-dA@mail.gmail.com>
Date: Fri, 8 Mar 2024 09:16:14 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: yunhui cui <cuiyunhui@...edance.com>
Cc: Palmer Dabbelt <palmer@...belt.com>, Paul Walmsley <paul.walmsley@...ive.com>, aou@...s.berkeley.edu, 
	xuzhipeng.1973@...edance.com, alexghiti@...osinc.com, samitolvanen@...gle.com, 
	bp@...en8.de, xiao.w.wang@...el.com, jan.kiszka@...mens.com, 
	kirill.shutemov@...ux.intel.com, nathan@...nel.org, 
	linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-efi@...r.kernel.org, Conor Dooley <conor@...nel.org>, 
	Heinrich Schuchardt <heinrich.schuchardt@...onical.com>
Subject: Re: [External] Re: [PATCH 3/3] efistub: fix missed the initialization
 of gp

On Fri, 8 Mar 2024 at 08:10, yunhui cui <cuiyunhui@...edance.com> wrote:
>
> Hi Ard,
>
> On Fri, Mar 8, 2024 at 12:49 AM Ard Biesheuvel <ardb@...nel.org> wrote:
> >
> > On Thu, 7 Mar 2024 at 04:19, yunhui cui <cuiyunhui@...edance.com> wrote:
> > >
..
> > >
> > > From the logic of binutils, if "__global_pointer$" exists, it is
> > > possible to use GP for optimization. For RISC-V, "__global_pointer$"
> > > was introduced in commit "fbe934d69eb7e". Therefore, for the system as
> > > a whole, we should keep using GP uniformly.
> >
> > There is no 'system as a whole' that can use GP 'uniformly'
> >
> > The EFI stub is a separate executable that runs from a different
> > mapping of memory, in an execution context managed by the firmware. It
> > happens to be linked into the same executable as the vmlinux kernel.
> >
> > > The root cause of this
> > > problem is that GP is not loaded, rather than "On RISC-V, we also
> > > avoid GP based relocations..." as commit "d2baf8cc82c17" said.
> >
> > GP is not loaded because in the EFI firmware context, there is no safe
> > way to rely on it.
> >
> > > We need
> > > to address problems head-on, rather than avoid them.
> > >
> >
> > So what solution are you proposing for the potential GP conflicts
> > between the boot loader, the Linux EFI stub and the firmware?
>
>
> The GP register values are now loaded in the arch/riscv/kernel/head.S
> and arch/riscv/kernel/suspend_entry.S files.
>
> Let's think about EFI runtimeservice. If the EFI firmware code uses GP
> registers but the compiler does not avoid GP, and kernel uses the
> callback function provided by EFI, is there a problem? Is it possible
> to solve the problem only by making the firmware code not use GP at
> all and compiling options to avoid using GP?
>

EFI runtime services do not use callbacks, and execute in a context
that is entirely owned by the OS. So this is one place where EFI
firmware cannot use GP at all even if the UEFI spec permitted it.

> The same goes for efistub.
>

Not really. The UEFI spec seems to suggest that *system* firmware
should not touch GP or make any assumptions about its value, but it
doesn't say anything about EFI applications such as the EFI stub or
GRUB.

> So the way to solve this problem is that the firmware does not use GP
> optimization. Does this allow efistub to load the GP register?
>

What about GRUB or other bootloaders that are loaded before the
kernel, but are still active while the EFI stub is executing? Who gets
to own GP in this scenario?