From: Jens Remus <jremus@linux.ibm.com>
To: Dylan Hatch <dylanbhatch@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Weinan Liu <wnliu@google.com>, Will Deacon <will@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Indu Bhagat <ibhagatgnu@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Jiri Kosina <jikos@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Prasanna Kumar T S M <ptsm@linux.microsoft.com>,
Puranjay Mohan <puranjay@kernel.org>, Song Liu <song@kernel.org>,
joe.lawrence@redhat.com, linux-toolchains@vger.kernel.org,
linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Randy Dunlap <rdunlap@infradead.org>,
Heiko Carstens <hca@linux.ibm.com>
Subject: Re: [PATCH v5 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION
Date: Thu, 30 Apr 2026 12:04:00 +0200 [thread overview]
Message-ID: <6fb474e6-7e54-408b-a3d9-9e13c674740c@linux.ibm.com> (raw)
In-Reply-To: <20260428183643.3796063-8-dylanbhatch@google.com>
On 4/28/2026 8:36 PM, Dylan Hatch wrote:
> Generalize the __safe* helpers to support a non-user-access code path.
>
> This requires arch-specific function address validation. This is because
> arm64 vmlinux keeps .exit.text (normally discarded), and .rodata.text
> sections both of which lie outside the bounds of the normal .text.
> .rodata.text contains code that is never executed by the kernel mapping,
> but for which the toolchain nonetheless generates sframe data, and needs
> to be considered valid for a PC lookup.
>
> Additionally .init.text lies outside .text for all arches and must be
> accounted for as well.
> diff --git a/arch/arm64/include/asm/unwind_sframe.h b/arch/arm64/include/asm/unwind_sframe.h
> @@ -2,7 +2,54 @@
> #ifndef _ASM_ARM64_UNWIND_SFRAME_H
> #define _ASM_ARM64_UNWIND_SFRAME_H
>
> +#include <linux/module.h>
> +#include <linux/sframe.h>
> +#include <asm/sections.h>
> +
> #define SFRAME_REG_SP 31
> #define SFRAME_REG_FP 29
>
> +static inline bool sframe_func_start_addr_valid(struct sframe_section *sec,
> + unsigned long func_addr)
> +{
> + /* Common case for unwinding */
> + if (sec->text_start <= func_addr && func_addr < sec->text_end)
> + return true;
> +
> + if (sec->sec_type != SFRAME_KERNEL)
> + return false;
> +
> + /*
> + * Account for vmlinux and module code outside the normal .text section.
> + * The toolchain still generates sframe data for these functions, so
> + * sframe lookups on them should be allowed.
> + */
> + if (sec == &kernel_sfsec) {
> + if (is_kernel_inittext(func_addr))
> + return true;
> +
> + /* .exit.text is retained in vmlinux on arm64. */
> + if (func_addr >= (unsigned long)__exittext_begin &&
> + func_addr < (unsigned long)__exittext_end)
> + return true;
> +
> +
Nit: Superfluous empty line (2 instead of 1).
> + /*
> + * .rodata.text is never executed from the kernel mapping, but
> + * still has sframe data
> + */
> + if (func_addr >= (unsigned long)_srodatatext &&
> + func_addr < (unsigned long)_erodatatext)
> + return true;
> + } else {
> + struct module *mod = container_of(sec, struct module,
> + arch.sframe_sec);
This currently does not work properly when sframe_validate_section() is
called from sframe_module_init(), which operates on a temporary struct
sframe_section section, that is not (yet) the one in struct module. See
my feedback to the respective patch for how to resolve.
> + if (within_module_mem_type(func_addr, mod, MOD_INIT_TEXT))
> + return true;
> + }
> +
> + return false;
> +}
> +#define sframe_func_start_addr_valid sframe_func_start_addr_valid
> +
> #endif /* _ASM_ARM64_UNWIND_SFRAME_H */
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
next prev parent reply other threads:[~2026-04-30 10:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 18:36 [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 1/8] sframe: Allow kernelspace sframe sections Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 2/8] arm64, unwind: build kernel with sframe V3 info Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 3/8] arm64: entry: add unwind info for various kernel entries Dylan Hatch
2026-04-29 15:26 ` Mark Rutland
2026-05-15 3:30 ` Dylan Hatch
2026-05-15 8:58 ` Mark Rutland
2026-04-28 18:36 ` [PATCH v5 4/8] sframe: Provide PC lookup for vmlinux .sframe section Dylan Hatch
2026-04-28 18:36 ` [PATCH v5 5/8] sframe: Allow unsorted FDEs Dylan Hatch
2026-04-30 10:04 ` Jens Remus
2026-04-28 18:36 ` [PATCH v5 6/8] arm64/module, sframe: Add sframe support for modules Dylan Hatch
2026-04-30 10:04 ` Jens Remus
2026-04-28 18:36 ` [PATCH v5 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION Dylan Hatch
2026-04-30 10:04 ` Jens Remus [this message]
2026-04-28 18:36 ` [PATCH v5 8/8] unwind: arm64: Use sframe to unwind interrupt frames Dylan Hatch
2026-05-01 16:46 ` Mark Rutland
2026-05-04 8:47 ` Jens Remus
2026-05-05 10:29 ` Mark Rutland
2026-05-05 15:52 ` Jens Remus
2026-05-12 3:00 ` Dylan Hatch
2026-05-12 8:55 ` Jens Remus
2026-05-12 10:18 ` Mark Rutland
2026-05-12 10:07 ` Mark Rutland
2026-04-29 17:18 ` [PATCH v5 0/8] unwind, arm64: add sframe unwinder for kernel Mark Rutland
2026-04-30 10:11 ` Jens Remus
2026-05-12 1:10 ` Dylan Hatch
2026-05-15 11:32 ` Mostafa Saleh
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=6fb474e6-7e54-408b-a3d9-9e13c674740c@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=dylanbhatch@google.com \
--cc=hca@linux.ibm.com \
--cc=ibhagatgnu@gmail.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=ptsm@linux.microsoft.com \
--cc=puranjay@kernel.org \
--cc=rdunlap@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
--cc=will@kernel.org \
--cc=wnliu@google.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.