Received-SPF: pass (google.com: domain of linux-kernel+bounces-96635-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <CAMj1kXH1oMbONoHFMPaatfaqrHNE2ryfrG7kw-7J-eFsuXkK-Q@mail.gmail.com>
 <mhng-c53211c1-4708-459a-bdc5-6e013c2adaee@palmer-ri-x1c9>
 <CAMj1kXEFqMx8qUHQEbg=OqbG-H0Zpj-nWu=a6qhhvNEZPO7f4Q@mail.gmail.com>
 <CAMj1kXG4SXsBfNqWMRUJ+AVv=6trWUAow-f8Mk5oKCpO=WueFg@mail.gmail.com>
 <CAEEQ3wkN3HDUuPDfWTn4kTxKH03OaRxBTFru3jJzZgW+BVhABg@mail.gmail.com>
 <CAMj1kXHuKbaXqWuFuMXhfL1_2w05CfJrk2uAPOW2HNHdpEnxXA@mail.gmail.com> <CAEEQ3wnv47x+FXYQ1=DdQdgRrp_EgX+C9eH+-JMPWh5p2450Zw@mail.gmail.com>
In-Reply-To: <CAEEQ3wnv47x+FXYQ1=DdQdgRrp_EgX+C9eH+-JMPWh5p2450Zw@mail.gmail.com>
From: Ard Biesheuvel <ardb@kernel.org>
Date: Fri, 8 Mar 2024 09:16:14 +0100
Message-ID: <CAMj1kXFE_G5-od5kbOiU_4D7dwjksdrMTofHfYsLkjFtZDz-dA@mail.gmail.com>
Subject: Re: [External] Re: [PATCH 3/3] efistub: fix missed the initialization
 of gp
To: yunhui cui <cuiyunhui@bytedance.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, aou@eecs.berkeley.edu, 
	xuzhipeng.1973@bytedance.com, alexghiti@rivosinc.com, samitolvanen@google.com, 
	bp@alien8.de, xiao.w.wang@intel.com, jan.kiszka@siemens.com, 
	kirill.shutemov@linux.intel.com, nathan@kernel.org, 
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, 
	linux-efi@vger.kernel.org, Conor Dooley <conor@kernel.org>, 
	Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 8 Mar 2024 at 08:10, yunhui cui <cuiyunhui@bytedance.com> wrote:
>
> Hi Ard,
>
> On Fri, Mar 8, 2024 at 12:49=E2=80=AFAM Ard Biesheuvel <ardb@kernel.org> =
wrote:
> >
> > On Thu, 7 Mar 2024 at 04:19, yunhui cui <cuiyunhui@bytedance.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 a=
s
> > > 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?