From: Catalin Marinas <catalin.marinas@arm.com>
To: Jinjie Ruan <ruanjinjie@huawei.com>
Cc: will@kernel.org, mark.rutland@arm.com, pratyush@kernel.org,
leitao@debian.org, mpilaniy@redhat.com, yeoreum.yun@arm.com,
graf@amazon.com, pasha.tatashin@soleen.com,
akpm@linux-foundation.org, baoquan.he@linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rppt@kernel.org
Subject: Re: [PATCH v8] arm64: kexec_file: Stop using the Image text_offset
Date: Fri, 6 Nov 2026 17:07:06 +0000 [thread overview]
Message-ID: <au4JOjnQlx2aSpiE@arm.com> (raw)
In-Reply-To: <20261105125442.2282987-1-ruanjinjie@huawei.com>
On Thu, Nov 05, 2026 at 08:54:42PM +0800, Jinjie Ruan wrote:
> image_load() adds text_offset to kernel_segment->mem and subtracts it
> from kernel_segment->memsz. For CMA backed segments this breaks the
> load path: the payload is copied to page_address(cma), which is the CMA
> base, while image->start is set to the adjusted address, so kexec jumps
> into the middle of the kernel. kimage_map_segment() has the same
> mismatch when a segment has been moved.
>
> The adjusted memsz also breaks the release path: the CMA pages are
> freed using segment->memsz >> PAGE_SHIFT, which is fewer than were
> allocated, leaking the tail of the allocation.
>
> Since commit 751c263bb74f ("arm64: remove TEXT_OFFSET randomization")
This commit only removed the randomisation. The one you want mentioned
here is cfa7ede20f13 ("arm64: set TEXT_OFFSET to 0x0 in preparation for
removing it entirely"). Although this removing never happened (see more
below).
> TEXT_OFFSET is always zero. This has been upstream since v5.8, so no
> LTS kernel carries a non-zero text_offset. Drop the adjustment and
> reject images with a non-zero value instead of booting them from a
> wrong address. With the adjustment gone, segments stay at their CMA
> base and the release size matches the allocation.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mike Rapoport <rppt@kernel.org>
> Link: https://lore.kernel.org/all/20260921090450.807575-2-ruanjinjie@huawei.com/
> Link: https://lore.kernel.org/all/20260921090450.807575-3-ruanjinjie@huawei.com/
> Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation")
> Suggested-by: Mike Rapoport <rppt@kernel.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> v2:
> - Split out from the patch set.
> - Link to v7: https://lore.kernel.org/all/20261026075201.699550-1-ruanjinjie@huawei.com/
> ---
> arch/arm64/kernel/kexec_image.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
> index 78b1f956d8d7..7d6baea3d28f 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -80,12 +80,17 @@ static void *image_load(struct kimage *image,
> kbuf.bufsz = kernel_len;
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> kbuf.memsz = le64_to_cpu(h->image_size);
> + /*
> + * Pre-v5.8 images carry a non-zero text_offset, which is no longer
> + * honored; reject them instead of loading them at a wrong address.
> + */
> text_offset = le64_to_cpu(h->text_offset);
> + if (text_offset) {
> + pr_err("Unsupported Image text_offset 0x%lx\n", text_offset);
> + return ERR_PTR(-ENOEXEC);
> + }
If it's only CMA getting it wrong, can we not just set
image->no_cma = true here and continue as normal?
While text_offset is 0 now, I don't think we concluded it should be
deprecated. There was a recent push back on the attempt to document the
always 0 behaviour:
https://lore.kernel.org/all/20260604140839.1930847-1-linux@rasmusvillemoes.dk/
--
Catalin
next prev parent reply other threads:[~2026-11-06 17:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 12:54 [PATCH v8] arm64: kexec_file: Stop using the Image text_offset Jinjie Ruan
2026-11-06 17:07 ` Catalin Marinas [this message]
2026-11-09 3:47 ` Jinjie Ruan
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=au4JOjnQlx2aSpiE@arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=graf@amazon.com \
--cc=leitao@debian.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mpilaniy@redhat.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=ruanjinjie@huawei.com \
--cc=will@kernel.org \
--cc=yeoreum.yun@arm.com \
/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.