linux-kernel - Re: [PATCH v4.1 06/10] x86/entry/vdso32: remove open-coded DWARF in sigreturn.S

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0ee773dea213f6efbdac03009ee80f350b17c949.camel@xry111.site>
Date: Tue, 10 Feb 2026 12:45:53 +0800
From: Xi Ruoyao <xry111@...111.site>
To: "H. Peter Anvin" <hpa@...or.com>, Jens Remus <jremus@...ux.ibm.com>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>, "Peter Zijlstra (Intel)"	
 <peterz@...radead.org>, Theodore Ts'o <tytso@....edu>, Thomas
 Weißschuh <thomas.weissschuh@...utronix.de>, Xin Li
 <xin@...or.com>, Andrew Cooper <andrew.cooper3@...rix.com>, Andy Lutomirski
 <luto@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, Borislav Petkov
 <bp@...en8.de>, Brian Gerst <brgerst@...il.com>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Ingo Molnar	 <mingo@...hat.com>, James Morse
 <james.morse@....com>, Jarkko Sakkinen	 <jarkko@...nel.org>, Josh Poimboeuf
 <jpoimboe@...nel.org>, Kees Cook	 <kees@...nel.org>, Nam Cao
 <namcao@...utronix.de>, Oleg Nesterov <oleg@...hat.com>,  Perry Yuan
 <perry.yuan@....com>, Thomas Gleixner <tglx@...utronix.de>, Thomas Huth
 <thuth@...hat.com>,  Uros Bizjak <ubizjak@...il.com>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	linux-sgx@...r.kernel.org, x86@...nel.org, Indu Bhagat
 <indu.bhagat@...cle.com>,  Claudiu Zissulescu-Ianculescu
 <claudiu.zissulescu-ianculescu@...cle.com>, Heiko Carstens
 <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH v4.1 06/10] x86/entry/vdso32: remove open-coded DWARF in
 sigreturn.S

On Mon, 2026-02-09 at 20:15 -0800, H. Peter Anvin wrote:
> On February 9, 2026 7:11:25 PM PST, Xi Ruoyao <xry111@...111.site> wrote:
> > On Mon, 2026-02-02 at 19:57 -0800, H. Peter Anvin wrote:
> > > That hack dates back from before the signal frame extension. It is no
> > > longer necessary.
> > 
> > Unfortunately at least it seems libgcc unwinder does not handle the
> > signal frame extension properly.  The code reads:
> > 
> >  fde = _Unwind_Find_FDE (context->ra + _Unwind_IsSignalFrame (context) - 1, 
> >                          &context->bases);
> >  if (fde == NULL)
> >    {    
> > #ifdef MD_FALLBACK_FRAME_STATE_FOR
> >      /* Couldn't find frame unwind info for this function.  Try a
> >         target-specific fallback mechanism.  This will necessarily
> >         not provide a personality routine or LSDA.  */
> >      return MD_FALLBACK_FRAME_STATE_FOR (context, fs); 
> > #else
> >      return _URC_END_OF_STACK;
> > #endif
> >    }    
> > 
> >  fs->pc = context->bases.func;
> > 
> >  cie = get_cie (fde);
> >  insn = extract_cie_info (cie, context, fs); 
> > 
> > Thus, it indeed attempts to avoid subtracting 1 for a signal frame, but
> > ... _Unwind_IsSignalFrame (context) actually extracts a flag in context
> > which will only be raised up by extract_cie_info.
> > 
> > Or am I missing something here?
> > 
> 
> Oh, good grief...
> 
> How does this possibly work on non-x86 platforms?

On ARM64 the vdso does not have eh_frame_hdr at all, on LoongArch
eh_frame_hdr is empty (note that an ampty en_frame_hdr is actually buggy
and I'm trying to fix it), so _Unwind_Find_FDE returns NULL and libgcc
falls back to MD_FALLBACK_FRAME_STATE_FOR, which handles the sigreturn
trampoline using some machine-dependant logic.

On RISC-V things are more theatrical: the sigreturn trampoline happens
to be at the beginning of the vdso .text section, so after subtracting 1
from the PC, the result is out of the .text section and so not in any
FDE.  Thus _Unwind_Find_FDE returns NULL and libgcc again falls back to
MD_FALLBACK_FRAME_STATE_FOR.

If the RISC-V sigreturn trampoline was not the first in .text,
subtracting 1 would cause the PC to be in the FDE of the previous
function and then _Unwind_Find_FDE would return that FDE, then RISC-V
would have some big trouble.

I've not taken a serious look at other architectures yet.

-- 
Xi Ruoyao <xry111@...111.site>