All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Remus <jremus@linux.ibm.com>
To: Dylan Hatch <dylanbhatch@google.com>
Cc: Indu Bhagat <ibhagatgnu@gmail.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Weinan Liu <wnliu@google.com>, Will Deacon <will@kernel.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Indu Bhagat <indu.bhagat@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jiri Kosina <jikos@kernel.org>,
	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,
	Heiko Carstens <hca@linux.ibm.com>
Subject: Re: [PATCH v3 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION.
Date: Tue, 21 Apr 2026 10:33:29 +0200	[thread overview]
Message-ID: <887de7b5-046c-4f68-b44c-8a1aaf2635e7@linux.ibm.com> (raw)
In-Reply-To: <CADBMgpzBvKTvRKHmLbEF301S_DnCg6SRETkMh6jPo-1hOEEZVw@mail.gmail.com>

On 4/21/2026 3:29 AM, Dylan Hatch wrote:
> On Mon, Apr 20, 2026 at 5:31 AM Jens Remus <jremus@linux.ibm.com> wrote:
>>
>> On 4/20/2026 7:02 AM, Dylan Hatch wrote:
>>> On Thu, Apr 16, 2026 at 8:04 AM Jens Remus <jremus@linux.ibm.com> wrote:
>>>> On 4/6/2026 8:49 PM, Dylan Hatch wrote:
>>
>>>>> Generalize the __safe* helpers to support a non-user-access code path.
>>>>> Allow for kernel FDE read failures due to the presence of .rodata.text.
>>>>> This section contains code that can't be executed by the kernel
>>>>> direclty, and thus lies ouside the normal kernel-text bounds.
>>>>
>>>> Nits: s/direclty/directly/ s/ouside/outside/
>>>>
>>>> Could you please explain the issue?  How/why does .sframe for
>>>> .rodata.text pose an issue for .sframe verification?
>>>
>>> __read_fde checks that the fde_addr it extracts is within the bounds
>>> of sec->text_start and sec->text_end. In the case of the vmlinux
>>
>> Looking at the existing check in __read_fde(), do you agree that it is
>> wrong, as sec->text_end IIUC points behind .text and thus the check
>> should be:
>>
>>         if (func_addr < sec->text_start || func_addr >= sec->text_end)
>>                 return -EINVAL;
> 
> I agree this is correct. Is this a fix that would be folded into your
> previous patch series?

Yes.  I would send a new version once we have clarified how to move
forward in general.

>>> Alternatively, we can check for FDEs located
>>> in .rodata.text during validation, but this seems to only be present
>>> in arm64, so maybe we would need an arch-specific hook to do this? I'm
>>> open to suggestions.
>>
>> Maybe that is better than ignoring __read_fde() failures?  I first
>> thought this would get nasty, but maybe it would not be too bad.
>> Following is what I came up with (note tabs replaced by spaces due to
>> copy&paste from terminal):

>> diff --git a/include/linux/sframe.h b/include/linux/sframe.h
>> @@ -63,6 +63,10 @@ struct sframe_section {
>>         unsigned long           sframe_end;
>>         unsigned long           text_start;
>>         unsigned long           text_end;
>> +#if defined(CONFIG_SFRAME_UNWINDER) && defined(CONFIG_ARM64)
>> +       unsigned long           rodatatext_start;
>> +       unsigned long           rodatatext_end;
>> +#endif
> 
> It looks to me like .rodata.text only exists for vmlinux. I wonder if
> in sframe_func_start_addr_valid we can just use the global
> _srodatatext and _erodatatext after identifying if an sframe_section
> corresponds to vmlinux (kernel_sfsec)? That way we don't need to add
> these extra fields.

Sure.  I don't have and preferences.

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/



  reply	other threads:[~2026-04-21  8:34 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-06 18:49 [PATCH v3 0/8] unwind, arm64: add sframe unwinder for kernel Dylan Hatch
2026-04-06 18:49 ` [PATCH v3 1/8] sframe: Allow kernelspace sframe sections Dylan Hatch
2026-04-14 12:09   ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 2/8] arm64, unwind: build kernel with sframe V3 info Dylan Hatch
2026-04-06 21:36   ` Randy Dunlap
2026-04-14 12:43   ` Jens Remus
2026-04-18  0:20     ` Dylan Hatch
2026-04-20 12:16       ` Jens Remus
2026-04-20 12:44   ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 3/8] arm64: entry: add unwind info for various kernel entries Dylan Hatch
2026-04-16 14:09   ` Jens Remus
2026-04-16 16:49   ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 4/8] sframe: Provide PC lookup for vmlinux .sframe section Dylan Hatch
2026-04-16 15:10   ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 5/8] sframe: Allow unsorted FDEs Dylan Hatch
2026-04-16 14:57   ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 6/8] arm64/module, sframe: Add sframe support for modules Dylan Hatch
2026-04-17 14:07   ` Jens Remus
2026-04-20  9:54   ` Jens Remus
2026-04-06 18:49 ` [PATCH v3 7/8] sframe: Introduce in-kernel SFRAME_VALIDATION Dylan Hatch
2026-04-16 15:04   ` Jens Remus
2026-04-20  5:02     ` Dylan Hatch
2026-04-20 12:30       ` Jens Remus
2026-04-21  1:29         ` Dylan Hatch
2026-04-21  8:33           ` Jens Remus [this message]
2026-04-06 18:50 ` [PATCH v3 8/8] unwind: arm64: Use sframe to unwind interrupt frames Dylan Hatch
2026-04-17 15:45   ` Jens Remus
2026-04-20  5:56     ` Dylan Hatch
2026-04-20  8:42       ` Jens Remus
2026-04-14 16:10 ` [PATCH v3 0/8] unwind, arm64: add sframe unwinder for kernel Jens Remus

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=887de7b5-046c-4f68-b44c-8a1aaf2635e7@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=indu.bhagat@oracle.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=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.