mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Weinan Liu" <wnliu@google.com>, "Will Deacon" <will@kernel.org>,
	"Indu Bhagat" <ibhagatgnu@gmail.com>,
	"Dylan Hatch" <dylanbhatch@google.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Jens Remus" <jremus@linux.ibm.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Josh Poimboeuf" <jpoimboe@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	"Song Liu" <song@kernel.org>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-toolchains@vger.kernel.org,
	"Puranjay Mohan" <puranjay@kernel.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Mostafa Saleh" <smostafa@google.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Prasanna Kumar T S M" <ptsm@linux.microsoft.com>,
	joe.lawrence@redhat.com, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v8 06/11] arm64/sframe: Validate IP addresses
Date: Wed, 07 Oct 2026 12:14:56 +0000	[thread overview]
Message-ID: <sashiko-outbox-162993@kernel.org> (raw)
In-Reply-To: <20261007114335.440322-7-dylanbhatch@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] unwind: noinstr violation via static inline callees in sframe_find()
--

commit e12d5712c137b31d5aeba1eafd95262908a336d3
Author: Dylan Hatch <dylanbhatch@google.com>

arm64/sframe: Validate IP addresses

This commit adds validation for instruction pointers during sframe unwinding.
It introduces architecture-specific checks for arm64 to ensure the IPs fall
within valid kernel or module text ranges, handling special sections like
.exit.text and .rodata.text.

[ ... ]
> diff --git a/arch/arm64/include/asm/unwind_sframe.h b/arch/arm64/include/asm/unwind_sframe.h
> new file mode 100644
> index 0000000000000..1b45d328c746f
> --- /dev/null
> +++ b/arch/arm64/include/asm/unwind_sframe.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_ARM64_UNWIND_SFRAME_H
> +#define _ASM_ARM64_UNWIND_SFRAME_H
> +
> +#include <linux/module.h>
> +#include <linux/sframe.h>
> +#include <asm/sections.h>
> +
> +static __always_inline bool sframe_is_kernel_ip_valid(unsigned long ip)
> +{
> +	if (__is_kernel_text(ip) || is_kernel_inittext(ip))
> +		return true;

[Severity: Low]
Since sframe_find() is marked noinstr and calls this helper, marking
sframe_is_kernel_ip_valid() as __always_inline helps prevent it from being
outlined. However, __is_kernel_text() and is_kernel_inittext() are standard
static inline functions. Could the compiler decide to outline these nested
helpers into the instrumentable .text section?

If that happens, objtool validation might fail during the build, and it could
theoretically result in recursive instrumentation faults (e.g., KASAN) if
called during NMI stack unwinding.

> +
> +	/* .exit.text is retained in vmlinux on arm64. */
> +	if (ip >= (unsigned long)__exittext_begin &&
[ ... ]
> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> index 33883408581da..c95fcb63e7eaf 100644
> --- a/kernel/unwind/sframe.c
> +++ b/kernel/unwind/sframe.c
[ ... ]
> @@ -44,6 +44,45 @@ struct sframe_fre_internal {
[ ... ]
> +#ifdef CONFIG_MODULES
> +
> +static __always_inline bool sframe_is_sec_module_ip_valid(struct sframe_section *sec,
> +							  unsigned long ip)
> +{
> +	struct module *mod = container_of(sec, struct module, sframe_sec);
> +
> +	return within_module_mem_type(ip, mod, MOD_TEXT) ||
> +		within_module_mem_type(ip, mod, MOD_INIT_TEXT);

[Severity: Low]
Similarly, within_module_mem_type() is a regular static inline function
called from the noinstr path. Does this present the same outlining risk
as the kernel text helpers above?

> +}
> +
> +#else

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261007114335.440322-1-dylanbhatch@google.com?part=6

  reply	other threads:[~2026-10-07 12:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 11:43 [PATCH v8 00/11] unwind, arm64: add sframe unwinder for kernel Dylan Hatch
2026-10-07 11:43 ` [PATCH v8 01/11] arm64, unwind: build kernel with sframe V3 info Dylan Hatch
2026-10-07 11:56   ` sashiko-bot
2026-10-07 11:43 ` [PATCH v8 02/11] arm64/sframe: Read vmlinux .sframe header Dylan Hatch
2026-10-07 11:43 ` [PATCH v8 03/11] sframe: Add support for reading vmlinux .sframe contents Dylan Hatch
2026-10-07 11:43 ` [PATCH v8 04/11] sframe: Separate reading of FRE from reading of FRE data words Dylan Hatch
2026-10-07 11:43 ` [PATCH v8 05/11] module, sframe: Add sframe support for modules Dylan Hatch
2026-10-07 12:09   ` sashiko-bot
2026-10-07 11:43 ` [PATCH v8 06/11] arm64/sframe: Validate IP addresses Dylan Hatch
2026-10-07 12:14   ` sashiko-bot [this message]
2026-10-07 11:43 ` [PATCH v8 07/11] sframe: Add debug helpers with object name Dylan Hatch
2026-10-07 12:09   ` sashiko-bot
2026-10-07 11:43 ` [PATCH v8 08/11] sframe: Add .sframe validation option Dylan Hatch
2026-10-07 11:43 ` [PATCH v8 09/11] arm64: entry: add unwind info for call_on_irq_stack() Dylan Hatch
2026-10-07 11:43 ` [PATCH v8 10/11] arm64, crypto/lib: Annotate leaf functions with CFI info Dylan Hatch
2026-10-07 11:43 ` [PATCH v8 11/11] unwind: arm64: Use sframe to unwind interrupt frames Dylan Hatch

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-162993@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=davem@davemloft.net \
    --cc=dylanbhatch@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ibhagatgnu@gmail.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=jremus@linux.ibm.com \
    --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=sashiko-reviews@lists.linux.dev \
    --cc=smostafa@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®