linux-kernel - Re: [RFC PATCH v1 08/16] unwind_user: Enable archs that save RA/FP in other registers

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: <ryuuuud2oistduo4exftjydws4bevd3ucsisuf4c7polup4bdv@6alhwwx4yyag>
Date: Thu, 17 Jul 2025 21:51:42 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Jens Remus <jremus@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	bpf@...r.kernel.org, x86@...nel.org, Steven Rostedt <rostedt@...nel.org>, 
	Heiko Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, 
	Ilya Leoshkevich <iii@...ux.ibm.com>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Peter Zijlstra <peterz@...radead.org>, 
	Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Andrii Nakryiko <andrii@...nel.org>, 
	Indu Bhagat <indu.bhagat@...cle.com>, "Jose E. Marchesi" <jemarch@....org>, 
	Beau Belgrave <beaub@...ux.microsoft.com>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>, 
	Florian Weimer <fweimer@...hat.com>, Sam James <sam@...too.org>
Subject: Re: [RFC PATCH v1 08/16] unwind_user: Enable archs that save RA/FP
 in other registers

On Thu, Jul 17, 2025 at 01:28:25PM +0200, Jens Remus wrote:
> >>  	}
> >>  
> >>  	/* Get the Frame Pointer (FP) */
> >> -	if (frame->fp_off && unwind_get_user_long(fp, cfa + frame->fp_off, state))
> >> +	switch (frame->fp.loc) {
> >> +	case UNWIND_USER_LOC_NONE:
> >> +		break;
> > 
> > The UNWIND_USER_LOC_NONE behavior is different here compared to above.
> 
> See my comments below.
> 
> > Do we also need UNWIND_USER_LOC_PT_REGS?
> 
> Sorry, I cannot follow.  Do you suggest to rename UNWIND_USER_LOC_REG to
> UNWIND_USER_LOC_PT_REGS?

I think I completely misunderstood the meaning of UNWIND_USER_LOC_NONE.
Never mind :-)

> >> +	case UNWIND_USER_LOC_STACK:
> >> +		if (!frame->fp.frame_off)
> >> +			goto done;
> >> +		if (unwind_get_user_long(fp, cfa + frame->fp.frame_off, state))
> >> +			goto done;
> >> +		break;
> >> +	case UNWIND_USER_LOC_REG:
> >> +		if (!IS_ENABLED(CONFIG_HAVE_UNWIND_USER_LOC_REG) || !topmost)
> >> +			goto done;
> > 
> > The topmost checking is *really* getting cumbersome, I do hope we can
> > get rid of that.
> 
> Restoring from arbitrary registers is only valid in the topmost frame,
> as their values (i.e. task_pt_regs(current)) are only available there.
> For other frames only SP, FP, and RA register values are available.
> 
> I think this test makes sense.  Is this test really that expensive?

ra_off=0 (UNWIND_USER_LOC_NONE) on a !topmost frame should never happen
unless the sframe entry is bad.  But 0 is *far* from the only potential
bad RA offset value.  In the absolute worst case of a 4 byte offset,
there are 4+ billion other possible bad values that can still go
undetected.

So I question the usefulness of those !topmost tests.  And they do add
complexity to the code.

-- 
Josh