From: Jason Gunthorpe <jgg@nvidia.com>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
mark.rutland@arm.com, will@kernel.org, catalin.marinas@arm.com,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH 4/5] efi/arm64: Expose struct efi_image_info via the image header
Date: Fri, 6 Nov 2026 10:34:18 -0400 [thread overview]
Message-ID: <20261106143418.GC770409@nvidia.com> (raw)
In-Reply-To: <20261106141936.2744481-11-ardb+git@google.com>
On Fri, Nov 06, 2026 at 03:19:41PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The zboot compressed kernel and the uncompressed Image both contain a
> copy of the EFI stub, and both are tightly coupled to the kernel image.
>
> However, the zboot stub is not linked into vmlinux like the ordinary EFI
> stub is, and so it does not have direct access to its symbols. This is
> needed today for things like image size and code size, but there are
> more cases coming (DRTM) where both stubs need to have a consistent view
> of these things.
>
> So add a struct efi_image_info that is built into vmlinux and exposed
> via the image header, so that zboot can access it easily.
I tried hard to avoid doing this because I didn't want to make the
struct layout ABI. I really see only negatives to that.
Putting it here and documenting it in the rst is going to encourage
other bootloaders to look inside it and try to read the contents. :(
The linker trick to inject the offset into zboot seemed better because
it completely prevents it from being ABI as nothing but the EFI stubs
can ever locate it.
Also, I wanted it to eventually be cross arch and I don't know if
other arches have any spare space like this.
Jason
next prev parent reply other threads:[~2026-11-06 14:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 14:19 [PATCH 0/5] efi: Expose loaded image properties via info struct Ard Biesheuvel
2026-11-06 14:19 ` [PATCH 1/5] efi/libstub: Make efi_remap_image() return efi_status_t Ard Biesheuvel
2026-11-06 14:19 ` [PATCH 2/5] efi/libstub: Pass a struct efi_image_info to efi_stub_common() Ard Biesheuvel
2026-11-06 14:19 ` [PATCH 3/5] efi/zboot: Disentangle efi_remap_image() from efi_cache_sync_image() Ard Biesheuvel
2026-11-06 14:19 ` [PATCH 4/5] efi/arm64: Expose struct efi_image_info via the image header Ard Biesheuvel
2026-11-06 14:34 ` Jason Gunthorpe [this message]
2026-11-06 14:19 ` [PATCH 5/5] efi/arm64: Drop build and linker script hacks to obtain image code size 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=20261106143418.GC770409@nvidia.com \
--to=jgg@nvidia.com \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=will@kernel.org \
/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