From: Ard Biesheuvel <ardb@kernel.org>
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>
Subject: Re: [External] Re: [PATCH 3/3] efistub: fix missed the initialization of gp
Date: Fri, 8 Mar 2024 09:16:14 +0100 [thread overview]
Message-ID: <CAMj1kXFE_G5-od5kbOiU_4D7dwjksdrMTofHfYsLkjFtZDz-dA@mail.gmail.com> (raw)
In-Reply-To: <CAEEQ3wnv47x+FXYQ1=DdQdgRrp_EgX+C9eH+-JMPWh5p2450Zw@mail.gmail.com>
On Fri, 8 Mar 2024 at 08:10, yunhui cui <cuiyunhui@bytedance.com> wrote:
>
> Hi Ard,
>
> On Fri, Mar 8, 2024 at 12:49 AM 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 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?
next prev parent reply other threads:[~2024-03-08 8:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 8:56 [PATCH 1/3] Revert "riscv/efistub: Ensure GP-relative addressing is not used" Yunhui Cui
2024-03-06 8:56 ` [PATCH 2/3] Revert "riscv/efistub: Tighten ELF relocation check" Yunhui Cui
2024-03-06 8:56 ` [PATCH 3/3] efistub: fix missed the initialization of gp Yunhui Cui
2024-03-06 9:36 ` Ard Biesheuvel
2024-03-06 12:34 ` [External] " yunhui cui
2024-03-06 13:02 ` Ard Biesheuvel
2024-03-06 13:09 ` Ard Biesheuvel
2024-03-06 13:30 ` yunhui cui
2024-03-06 15:21 ` Palmer Dabbelt
2024-03-06 15:44 ` Ard Biesheuvel
2024-03-06 16:15 ` Ard Biesheuvel
2024-03-06 17:11 ` Ard Biesheuvel
2024-03-07 3:19 ` yunhui cui
2024-03-07 16:48 ` Ard Biesheuvel
2024-03-08 7:09 ` yunhui cui
2024-03-08 8:16 ` Ard Biesheuvel [this message]
2024-03-06 9:02 ` [PATCH 1/3] Revert "riscv/efistub: Ensure GP-relative addressing is not used" Conor Dooley
2024-03-06 9:38 ` Ard Biesheuvel
2024-03-06 12:37 ` [External] " yunhui cui
2024-03-06 12:52 ` Jan Kiszka
2024-03-06 13:07 ` [External] " yunhui cui
2024-03-06 13:11 ` Ard Biesheuvel
2024-03-06 13:26 ` yunhui cui
2024-03-06 13:46 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMj1kXFE_G5-od5kbOiU_4D7dwjksdrMTofHfYsLkjFtZDz-dA@mail.gmail.com \
--to=ardb@kernel.org \
--cc=alexghiti@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=bp@alien8.de \
--cc=conor@kernel.org \
--cc=cuiyunhui@bytedance.com \
--cc=heinrich.schuchardt@canonical.com \
--cc=jan.kiszka@siemens.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samitolvanen@google.com \
--cc=xiao.w.wang@intel.com \
--cc=xuzhipeng.1973@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).