Re: [PATCH 4/5] efi/arm64: Expose struct efi_image_info via the image header

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Nov 06, 2026 at 04:51:09PM +0100, Ard Biesheuvel wrote:

> > Also, I wanted it to eventually be cross arch and I don't know if
> > other arches have any spare space like this.
> 
> Yeah so let's bring back the code injection hack but only for the
> offset of image info. 

OK, that great

> What I would still like to avoid (compared to your proposal) are:
> - having the efi_image_info pointer be a global that can be grabbed
> from anywhere, even though in zboot, it only becomes valid after
> the decompression has been performed;

Yeah, I liked what you did here by passing it through the call
chain. That's nice, I wasn't bold enough to try that.

> - putting every shared variable in the linker script.

It took me a bit to understand what this does:

@@ -68,6 +68,8 @@ asm("	.section \".rodata\", \"a\", %progbits;			" \
     "	.align	3;						" \
     "	.globl	efi_image_info;					" \
     "efi_image_info:						" \
+    "	.long	_text - efi_image_info;				" \
+    "	.long	__inittext_end - efi_image_info;		" \
     "	.previous						");
 
Generating a PC relative R_AARCH64_PREL32 relocation is a very clever
trick! I see no issue with it.

The .long should be expanded to 64 bits, I already got a kbuild 0-day
failure from some crazy kconfig that overflowed the 32 bits I had
originally. The linker script version did have assertions to detect
that.

It also still needs every shared variable to be put in the linker
script, these patches don't show it but these are still required:

PROVIDE(__efistub__text			= _text);
PROVIDE(__efistub___inittext_end       	= __inittext_end);

IMHO it would be a bit nicer to put the asm block in a file that
doesn't get the __efistub__ symbol renaming so even these provides are
not required? It is why I put it in the main build and not in the
stub, also I thought it would let it work better for x86 which doesn't
use the built in stub?

Jason