From: sashiko-bot@kernel.org
To: "Ard Biesheuvel" <ardb+git@google.com>, linux-efi@vger.kernel.org
Cc: "Ard Biesheuvel" <ardb@kernel.org>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Paul Walmsley" <pjw@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Huacai Chen" <chenhuacai@kernel.org>
Subject: Re: [PATCH v2 07/10] efi/libstub: riscv: Use struct efi_image_info to access image properties
Date: Tue, 10 Nov 2026 12:27:22 +0000 [thread overview]
Message-ID: <sashiko-outbox-207016@kernel.org> (raw)
In-Reply-To: <20261110121731.2728824-19-ardb+git@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Critical] efi/libstub: riscv: wrong image base and entry offset from
_text
--
commit 66c3f5bb26141f8dc9e6a6b6eea665f0e9187c52
Author: Ard Biesheuvel <ardb@kernel.org>
efi/libstub: riscv: Use struct efi_image_info to access image properties
This commit converts the RISC-V EFI stub to use struct efi_image_info
helpers instead of linker script symbol aliases to determine the kernel
image base, sizes, and entry offset.
> diff --git a/drivers/firmware/efi/libstub/riscv-stub.c b/drivers/firmware/efi/libstub/riscv-stub.c
> index 5cbc50a814e11..e8d66f6fe8e03 100644
> --- a/drivers/firmware/efi/libstub/riscv-stub.c
> +++ b/drivers/firmware/efi/libstub/riscv-stub.c
> @@ -20,7 +19,7 @@ unsigned long stext_offset(void)
> * of the file representation. So instead, we need to jump to the
> * actual entrypoint in the .text region of the image.
> */
> - return _start_kernel - _start;
> + return efistub_kernel_entry_offset(efistub_get_image_info());
> }
>
> efi_status_t handle_kernel_image(unsigned long *image_addr,
> @@ -30,13 +29,14 @@ efi_status_t handle_kernel_image(unsigned long *image_addr,
> efi_loaded_image_t *image,
> efi_handle_t image_handle)
> {
> - unsigned long kernel_size, kernel_codesize, kernel_memsize;
> + auto image_info = efistub_get_image_info();
> + unsigned long kernel_base = efistub_kernel_base(image_info);
> + unsigned long kernel_size = efistub_kernel_size(image_info);
> + unsigned long kernel_codesize = efistub_kernel_codesize(image_info);
> + unsigned long kernel_memsize = efistub_kernel_memsize(image_info);
> efi_status_t status;
>
> - kernel_size = _edata - _start;
> - kernel_codesize = __inittext_end - _start;
> - kernel_memsize = kernel_size + (_end - _edata);
> - *image_addr = (unsigned long)_start;
> + *image_addr = kernel_base;
> *reserve_size = kernel_memsize;
[Severity: Critical]
Does using struct efi_image_info here base the RISC-V image calculations on
_text instead of _start?
struct efi_image_info records _text_offset using REL_REF(_text), and the
efistub_kernel_*() helpers compute the base address, image sizes, and
efi_primary_entry (_start_kernel) offset relative to _text. On RISC-V,
however, _start and the .head.text section (which contains _start_kernel)
are placed before _text:
arch/riscv/kernel/vmlinux.lds.S:
_start = .;
HEAD_TEXT_SECTION
. = ALIGN(PAGE_SIZE);
.text : {
_text = .;
_stext = .;
As a result, handle_kernel_image() sets *image_addr to _text and omits
.head.text when efi_kaslr_relocate_kernel() checks alignment and copies the
image, while stext_offset() returns _start_kernel - _text (a negative
s32 offset that sign-extends to unsigned long), causing efi_enter_kernel()
to jump before the start of the image buffer and crash at boot.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110121731.2728824-12-ardb+git@google.com?part=7
next prev parent reply other threads:[~2026-11-10 12:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 12:17 [PATCH v2 00/10] efi: Expose loaded image properties via info struct Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:17 ` [PATCH v2 01/10] efi/zboot: arm64: Add missing barrier after cache maintenance Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:31 ` sashiko-bot
2026-11-10 12:17 ` [PATCH v2 02/10] efi/riscv: Rename __init_text_end to __inittext_end like other archs Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:17 ` [PATCH v2 03/10] efi/libstub: Avoid _end section marker in library code Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:17 ` [PATCH v2 04/10] efi/libstub: Capture loaded image information in struct efi_image_info Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:47 ` sashiko-bot
2026-11-10 12:17 ` [PATCH v2 05/10] efi/libstub: arm64: Use struct efi_image_info to access image properties Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:17 ` [PATCH v2 06/10] efi/libstub: loongarch: " Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:17 ` [PATCH v2 07/10] efi/libstub: riscv: " Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:27 ` sashiko-bot [this message]
2026-11-10 12:17 ` [PATCH v2 08/10] efi/libstub: Make efi_remap_image() return efi_status_t Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:17 ` [PATCH v2 09/10] efi/zboot: Disentangle efi_remap_image() from efi_cache_sync_image() Ard Biesheuvel
2026-11-10 12:17 ` Ard Biesheuvel
2026-11-10 12:39 ` sashiko-bot
2026-11-10 12:17 ` [PATCH v2 10/10] efi/libstub: arm64: Drop zboot code_size hack Ard Biesheuvel
2026-11-10 12:17 ` 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=sashiko-outbox-207016@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=chenhuacai@kernel.org \
--cc=jgg@nvidia.com \
--cc=linux-efi@vger.kernel.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.