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

[Ard Biesheuvel]

On Fri, 8 Mar 2024 at 08:10, yunhui cui <cuiyunhui@xxxxxxxxxxxxx> wrote:
>
> Hi Ard,
>
> On Fri, Mar 8, 2024 at 12:49 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> >
> > On Thu, 7 Mar 2024 at 04:19, yunhui cui <cuiyunhui@xxxxxxxxxxxxx> 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?