From: Jens Remus <jremus@linux.ibm.com>
To: Steven Rostedt <rostedt@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>
Cc: bpf@vger.kernel.org, sashiko@lists.linux.dev,
Indu Bhagat <ibhagatgnu@gmail.com>,
Dylan Hatch <dylanbhatch@google.com>
Subject: Re: [PATCH v14 18/19] unwind_user/sframe/x86: Enable sframe unwinding on x86
Date: Mon, 18 May 2026 17:33:45 +0200 [thread overview]
Message-ID: <3c9ee86e-b3d2-455d-9f4f-170e014dd127@linux.ibm.com> (raw)
In-Reply-To: <20260505190728.91695C2BCF4@smtp.kernel.org>
On 5/5/2026 9:07 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] SFrame unwinding uses incorrect DWARF register mappings for 32-bit (compat) user processes on x86_64.
> --
>
> commit 014ce7a38c83420c1017dd7293ec85cc9b4e45d6
> Author: Josh Poimboeuf <jpoimboe@kernel.org>
> unwind_user/sframe/x86: Enable sframe unwinding on x86
>
> This commit enables SFrame V3 unwinding on x86, which requires binutils 2.46.
> It introduces DWARF register mappings and sets the SFrame register constants.
>
>> diff --git a/arch/x86/include/asm/unwind_user.h b/arch/x86/include/asm/unwind_user.h
>> index f38f7c5ff1de1..b80f0ec0f7a74 100644
>> --- a/arch/x86/include/asm/unwind_user.h
>> +++ b/arch/x86/include/asm/unwind_user.h
>> @@ -15,6 +15,39 @@ static inline int unwind_user_word_size(struct pt_regs *regs)
>> return user_64bit_mode(regs) ? 8 : 4;
>> }
>>
>> +static inline int unwind_user_get_reg(unsigned long *val, unsigned int regnum)
>> +{
>> +#ifdef CONFIG_X86_64
>> + const struct pt_regs *regs = task_pt_regs(current);
>> +
SFrame is currently only supported on x86-64 (no 32-bit compat):
if (!user_64bit_mode(regs))
return -EINVAL;
>> + switch (regnum) {
>> + /* DWARF register numbers 0..15 */
>> + case 0: *val = regs->ax; break;
>> + case 1: *val = regs->dx; break;
>> + case 2: *val = regs->cx; break;
>> + case 3: *val = regs->bx; break;
>> + case 4: *val = regs->si; break;
>> + case 5: *val = regs->di; break;
>> + case 6: *val = regs->bp; break;
>> + case 7: *val = regs->sp; break;
>
> Does this code handle 32-bit (compat) user processes correctly?
>
> 32-bit (i386) processes use a different DWARF mapping where ESP is 4 and
> EBP is 5, but this code unconditionally uses the x86_64 DWARF register
> mapping (where register 4 is RSI and 7 is RSP).
>
> When an i386 application uses an SFrame V3 flexible FDE, the DWARF register
> number is explicitly encoded in the FRE data words. The generic unwinder
> sframe_init_cfa_rule_data() compares the register against the hardcoded
> SFRAME_REG_SP (which is 7 on x86_64).
>
> Since an i386 SFrame specifies 4 for SP, the check would fail and fall
> back to UNWIND_USER_CFA_RULE_REG_OFFSET with regnum = 4. Then
> unwind_user_next_common() would call unwind_user_get_reg(&cfa, 4), which
> would return regs->si instead of regs->sp.
>
> Could this break unwinding for 32-bit tasks by using the wrong registers
> (e.g., RSI acting as the stack pointer), leading to corrupted stack traces?
> Would the unwinder need to be explicitly disabled for compat tasks or
> dynamically adjust the DWARF mappings using user_64bit_mode(regs)?
>
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-05-18 15:33 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 12:16 [PATCH v14 00/19] unwind_deferred: Implement sframe handling Jens Remus
2026-05-05 12:17 ` [PATCH v14 01/19] unwind_user: Add generic and arch-specific headers to MAINTAINERS Jens Remus
2026-05-05 12:17 ` [PATCH v14 02/19] unwind_user/sframe: Add support for reading .sframe headers Jens Remus
2026-05-05 12:49 ` sashiko-bot
2026-05-06 13:42 ` Jens Remus
2026-05-07 14:55 ` Jens Remus
2026-05-08 23:02 ` Indu Bhagat
2026-05-11 10:05 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 03/19] unwind_user/sframe: Store .sframe section data in per-mm maple tree Jens Remus
2026-05-05 18:51 ` sashiko-bot
2026-05-06 13:50 ` Jens Remus
2026-05-06 15:21 ` Steven Rostedt
2026-05-12 15:52 ` Jens Remus
2026-05-20 14:48 ` Jens Remus
2026-05-18 15:22 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 04/19] x86/uaccess: Add unsafe_copy_from_user() implementation Jens Remus
2026-05-05 18:22 ` sashiko-bot
2026-05-06 14:13 ` Jens Remus
2026-05-06 15:05 ` Steven Rostedt
2026-05-06 14:09 ` Jens Remus
2026-05-06 15:03 ` Steven Rostedt
2026-05-06 21:13 ` David Laight
2026-05-06 21:17 ` David Laight
2026-05-05 12:17 ` [PATCH v14 05/19] unwind_user/sframe: Add support for reading .sframe contents Jens Remus
2026-05-05 18:59 ` sashiko-bot
2026-05-06 14:34 ` Jens Remus
2026-05-06 15:01 ` Steven Rostedt
2026-05-06 15:29 ` Jens Remus
2026-05-08 9:49 ` Jens Remus
2026-05-08 23:04 ` Indu Bhagat
2026-05-12 13:35 ` Jens Remus
2026-05-13 12:22 ` Steven Rostedt
2026-05-08 23:03 ` Indu Bhagat
2026-05-08 10:50 ` Jens Remus
2026-05-11 16:16 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 06/19] unwind_user/sframe: Detect .sframe sections in executables Jens Remus
2026-05-05 12:53 ` sashiko-bot
2026-05-06 14:56 ` Jens Remus
2026-05-06 15:36 ` Steven Rostedt
2026-05-08 23:05 ` Indu Bhagat
2026-05-05 12:17 ` [PATCH v14 07/19] unwind_user/sframe: Wire up unwind_user to sframe Jens Remus
2026-05-05 18:55 ` sashiko-bot
2026-05-07 16:18 ` Jens Remus
2026-05-08 23:07 ` Indu Bhagat
2026-05-11 16:46 ` Steven Rostedt
2026-05-05 12:17 ` [PATCH v14 08/19] unwind_user: Stop when reaching an outermost frame Jens Remus
2026-05-05 12:40 ` sashiko-bot
2026-05-06 15:01 ` Jens Remus
2026-05-06 15:40 ` Steven Rostedt
2026-05-05 12:17 ` [PATCH v14 09/19] unwind_user/sframe: Add support for outermost frame indication Jens Remus
2026-05-05 12:17 ` [PATCH v14 10/19] unwind_user/sframe: Remove .sframe section on detected corruption Jens Remus
2026-05-05 20:39 ` sashiko-bot
2026-05-07 16:23 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 11/19] unwind_user/sframe: Show file name in debug output Jens Remus
2026-05-05 18:46 ` sashiko-bot
2026-05-12 14:52 ` Jens Remus
2026-05-13 9:20 ` Jens Remus
2026-05-18 15:27 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 12/19] unwind_user/sframe: Add .sframe validation option Jens Remus
2026-05-05 18:32 ` sashiko-bot
2026-05-12 14:23 ` Jens Remus
2026-05-13 12:30 ` Steven Rostedt
2026-05-08 10:51 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 13/19] unwind_user: Enable archs that pass RA in a register Jens Remus
2026-05-05 18:35 ` sashiko-bot
2026-05-18 14:57 ` Jens Remus
2026-05-18 16:16 ` Jens Remus
2026-05-18 16:31 ` Steven Rostedt
2026-05-19 12:24 ` Jens Remus
2026-05-19 12:42 ` Steven Rostedt
2026-05-19 14:30 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 14/19] unwind_user: Flexible FP/RA recovery rules Jens Remus
2026-05-05 18:34 ` sashiko-bot
2026-05-18 15:08 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 15/19] unwind_user: Flexible CFA " Jens Remus
2026-05-05 12:17 ` [PATCH v14 16/19] unwind_user/sframe: Add support for SFrame V3 flexible FDEs Jens Remus
2026-05-05 18:55 ` sashiko-bot
2026-05-07 15:30 ` Jens Remus
2026-05-13 6:26 ` Indu Bhagat
2026-05-13 13:50 ` Jens Remus
2026-05-13 15:16 ` Steven Rostedt
2026-05-05 12:17 ` [PATCH v14 17/19] unwind_user/sframe: Separate reading of FRE from reading of FRE data words Jens Remus
2026-05-05 19:05 ` sashiko-bot
2026-05-07 16:01 ` Jens Remus
2026-05-05 12:17 ` [PATCH v14 18/19] unwind_user/sframe/x86: Enable sframe unwinding on x86 Jens Remus
2026-05-05 19:07 ` sashiko-bot
2026-05-18 15:33 ` Jens Remus [this message]
2026-05-05 12:17 ` [PATCH v14 19/19] unwind_user/sframe: Add prctl() interface for registering .sframe sections Jens Remus
2026-05-05 18:45 ` sashiko-bot
2026-05-07 14:14 ` Jens Remus
2026-05-05 12:25 ` [PATCH v14 00/19] unwind_deferred: Implement sframe handling 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=3c9ee86e-b3d2-455d-9f4f-170e014dd127@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=dylanbhatch@google.com \
--cc=ibhagatgnu@gmail.com \
--cc=jpoimboe@kernel.org \
--cc=rostedt@kernel.org \
--cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox