All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ard Biesheuvel" <ardb+git@google.com>, linux-efi@vger.kernel.org
Cc: mark.rutland@arm.com, will@kernel.org, catalin.marinas@arm.com,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Jason Gunthorpe" <jgg@nvidia.com>
Subject: Re: [PATCH 5/5] efi/arm64: Drop build and linker script hacks to obtain image code size
Date: Fri, 06 Nov 2026 14:33:33 +0000	[thread overview]
Message-ID: <sashiko-outbox-201588@kernel.org> (raw)
In-Reply-To: <20261106141936.2744481-12-ardb+git@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] efi/zboot: redundant full-image cache sync in
  efi_zboot_decompress()
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [High] efi/libstub: arm64: missing DSB ISH in efi_cache_sync_image()
  [1]
--

commit 579820756d50227a71aeb397996f2064f5e5696a
Author: Ard Biesheuvel <ardb@kernel.org>

efi/arm64: Drop build and linker script hacks to obtain image code size

This commit replaces the build-time symbol injection and linker script
logic for obtaining the kernel code size in EFI zboot with offsets stored
in struct efi_image_info, and updates efi_cache_sync_image() to use its
alloc_size argument.

> diff --git a/drivers/firmware/efi/libstub/arm64.c b/drivers/firmware/efi/libstub/arm64.c
> index 190cf180bb234..da6fa2f6c8219 100644
> --- a/drivers/firmware/efi/libstub/arm64.c
> +++ b/drivers/firmware/efi/libstub/arm64.c
> @@ -88,8 +88,6 @@ efi_status_t check_platform_features(void)
>  #define DCTYPE	"cvau"
>  #endif
>  
> -u32 __weak code_size;
> -
>  void efi_cache_sync_image(unsigned long image_base,
>  			  unsigned long alloc_size)
>  {
> @@ -100,7 +98,7 @@ void efi_cache_sync_image(unsigned long image_base,
>  	/* only perform the cache maintenance if needed for I/D coherency */
>  	if (!(ctr & BIT(CTR_EL0_IDC_SHIFT))) {
>  		unsigned long base = image_base;
> -		unsigned long size = code_size;
> +		unsigned long size = alloc_size;
>  
>  		do {
>  			asm("dc " DCTYPE ", %0" :: "r"(base));

[Severity: Low]
Does changing size from code_size to alloc_size cause efi_zboot_decompress()
to clean the data cache across the entire decompressed image allocation
before efi_zboot_remap_image() syncs the code region a second time?

Both gzip and zstd implementations of efi_zboot_decompress() still call
efi_cache_sync_image((unsigned long)out, outlen) with the full allocation
size (including rodata, data, and BSS), and efi_zboot_entry() then calls
efi_zboot_remap_image() -> efi_cache_sync_image(image_base, code_size)
immediately afterward.

[Severity: High]
This problem wasn't introduced by this patch, but is a dsb(ish) barrier
needed [1] between the data cache clean loop and ic ialluis in
efi_cache_sync_image()?

drivers/firmware/efi/libstub/arm64.c:efi_cache_sync_image() {
	...
	if (!(ctr & BIT(CTR_EL0_IDC_SHIFT))) {
		unsigned long base = image_base;
		unsigned long size = alloc_size;

		do {
			asm("dc " DCTYPE ", %0" :: "r"(base));
			base += lsize;
			size -= lsize;
		} while (size >= lsize);
	}

	asm("ic ialluis");
	dsb(ish);
	isb();
}

Without a barrier after the dc maintenance instructions, ic ialluis can
execute before the data cache cleans complete, allowing the instruction
cache to refetch stale instructions during early boot.

[1] https://sashiko.dev/#/bug/linux-3f5f98cd-053a-49ef-9e97-834ca6744a2c

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106141936.2744481-7-ardb+git@google.com?part=5

      reply	other threads:[~2026-11-06 14:33 UTC|newest]

Thread overview: 13+ 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:36   ` sashiko-bot
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:27   ` sashiko-bot
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:34   ` sashiko-bot
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
2026-11-06 15:51     ` Ard Biesheuvel
2026-11-06 17:09       ` Jason Gunthorpe
2026-11-06 14:19 ` [PATCH 5/5] efi/arm64: Drop build and linker script hacks to obtain image code size Ard Biesheuvel
2026-11-06 14:33   ` sashiko-bot [this message]

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=sashiko-outbox-201588@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=jgg@nvidia.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.