[PATCH v1] efi_loader: Handle GD_FLG_SKIP_RELOC

[Varadarajan Narayanan]

On Tue, Apr 01, 2025 at 10:02:05AM +0300, Ilias Apalodimas wrote:
> On Tue, 1 Apr 2025 at 09:46, Varadarajan Narayanan
> <quic_varada at quicinc.com> wrote:
> >
> > On Thu, Mar 27, 2025 at 11:22:58PM +0200, Ilias Apalodimas wrote:
> > > On Thu, 27 Mar 2025 at 08:12, Varadarajan Narayanan
> > > <quic_varada at quicinc.com> wrote:
> > > >
> > > > On Wed, Mar 26, 2025 at 09:28:04AM +0200, Ilias Apalodimas wrote:
> > > > > Hi Varadarajan
> > > > >
> > > > > On Wed, 26 Mar 2025 at 07:47, Varadarajan Narayanan
> > > > > <quic_varada at quicinc.com> wrote:
> > > > > >
> > > > > > If the EFI runtime services pointers are relocated even though
> > > > > > relocation is skipped, it corrupts some other data resulting in some
> > > > > > unexpected behaviour.
> > > > > >
> > > > > > In this specific case, it overwrote some page table entries resulting in
> > > > > > the device memory address range's mappings getting removed. Eventually,
> > > > > > after the completion of efi_runtime_relocate(), when a driver tries to
> > > > > > access its device's registers it crashes since the mappings are absent.
> > > > >
> > > > > How were those page table entries added?
> > > >
> > > > initr_caches ->
> > > >         enable_caches ->
> > > >                 setup_pgtables (arch/arm/mach-snapdragon/board.c)
> > > >
> > > > > The runtime service relocation might have overwritten those now, but
> > > > > since they are not in protected memory this can happen arbitrarily.
> > > >
> > > > To avoid relocating U-Boot, I had OR'ed GD_FLG_SKIP_RELOC to gd->flags
> > > > in init_sequence_f -> mach_cpu_init(). Hope that is the right place and
> > > > way to do it.
> > >
> > > I'll have a look at the relocation stuff, but off the top of my head,
> > > I don't remember.
> > >
> > > >
> > > > > > Signed-off-by: Varadarajan Narayanan <quic_varada at quicinc.com>
> > > > > > ---
> > > > > >  common/board_r.c | 3 ++-
> > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/common/board_r.c b/common/board_r.c
> > > > > > index 179259b00de..1dd3b96c2de 100644
> > > > > > --- a/common/board_r.c
> > > > > > +++ b/common/board_r.c
> > > > > > @@ -169,7 +169,8 @@ static int initr_reloc_global_data(void)
> > > > > >          */
> > > > > >         efi_save_gd();
> > > > > >
> > > > > > -       efi_runtime_relocate(gd->relocaddr, NULL);
> > > > > > +       if (!(gd->flags & GD_FLG_SKIP_RELOC))
> > > > > > +               efi_runtime_relocate(gd->relocaddr, NULL);
> > > > >
> > > > > Have you tested booting with EFI with this change?
> > > >
> > > > Yes, tested this with both GD_FLG_SKIP_RELOC set and not set.
> > > >
> > > > Used the command 'bootefi bootmgr' and Linux is able to boot.
> > >
> > > Have you tried to call any runtime services -- e.g efival -l will dump
> > > all the EFI variables
> >
> > Sorry for the delay. The test setup was busy. My U-boot doesn't seem to
> > have this command. Not sure if I'm missing some config.
> >
> >         => efival -l
> >         Unknown command 'efival' - try 'help'
> >
> > However, 'efidebug boot dump' works. Does that suffice?
>
> This runs at boottime. We want to test the variables at runtime so you
> have to boot linux.
> One of efibootmgr or efivar -l is enough

Please see below for 'efivar -l' output

	sh-5.2# dmesg | grep EFI
	[    0.000000] efi: EFI v2.11 by Das U-Boot
	[    0.001636] Remapping and enabling EFI services.

	sh-5.2# uname -a
	Linux qcs9100-ride-sx 6.6.65-qli-1.3-ver.1.1-dirty #1 SMP PREEMPT Wed Dec 11 15:13:43 UTC 2024 aarch64 GNU/Linux

	sh-5.2# efivar -l
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-StubFeatures
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-StubInfo
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeExecUSec
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntrySelected
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderEntries
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderDevicePartUUID
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderImageIdentifier
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFeatures
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareType
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderFirmwareInfo
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderInfo
	4a67b082-0a4c-41cf-b6c7-440b29bb8c4f-LoaderTimeInitUSec
	605dab50-e046-4300-abb6-3dd810dd8b23-ShimRetainProtocol
	8be4df61-93ca-11d2-aa0d-00e098032b8c-BootCurrent
	8be4df61-93ca-11d2-aa0d-00e098032b8c-OsIndicationsSupported
	8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLang
	8be4df61-93ca-11d2-aa0d-00e098032b8c-PlatformLangCodes
	8be4df61-93ca-11d2-aa0d-00e098032b8c-BootOrder
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0007
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0006
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0005
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0004
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0002
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0001
	8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0000
	8be4df61-93ca-11d2-aa0d-00e098032b8c-VendorKeys
	8be4df61-93ca-11d2-aa0d-00e098032b8c-DeployedMode
	8be4df61-93ca-11d2-aa0d-00e098032b8c-AuditMode
	8be4df61-93ca-11d2-aa0d-00e098032b8c-SetupMode
	8be4df61-93ca-11d2-aa0d-00e098032b8c-SecureBoot

Thanks
Varada

[ . . . ]