linux-hardening - Re: [PATCH] usercopy: delete __noreturn from usercopy

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: <20240306160248.oxeblpwa5zvplmgw@treble>
Date: Wed, 6 Mar 2024 08:02:48 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Jiangfeng Xiao <xiaojiangfeng@...wei.com>,
	Kees Cook <keescook@...omium.org>, Jann Horn <jannh@...gle.com>,
	gustavoars@...nel.org, akpm@...ux-foundation.org,
	peterz@...radead.org, dave.hansen@...ux.intel.com,
	kirill.shutemov@...ux.intel.com, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org, linux-mm@...ck.org,
	nixiaoming@...wei.com, kepler.chenxin@...wei.com,
	wangbing6@...wei.com, wangfangpeng1@...wei.com,
	douzhaolei@...wei.com, linux-arm-kernel@...ts.infradead.org,
	Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH] usercopy: delete __noreturn from usercopy_abort

On Wed, Mar 06, 2024 at 09:52:01AM +0000, Russell King (Oracle) wrote:
> On Tue, Mar 05, 2024 at 09:58:46AM -0800, Josh Poimboeuf wrote:
> > This is an off-by-one bug which is common in unwinders, due to the fact
> > that the address on the stack points to the return address rather than
> > the call address.
> > 
> > So, for example, when the last instruction of a function is a function
> > call (e.g., to a noreturn function), it can cause the unwinder to
> > incorrectly try to unwind from the function *after* the callee.
> 
> I suppose this can only happen in __noreturn functions because that
> can be:
> 
> foo:
> ...
> 	bl	bar
> ... end of function and thus next function ...
> 
> which results in LR pointing into the next function.
> 
> Would it make better sense to lookup the LR value winding it back by
> one instruction like ORC on x86 does (as you mention) rather than
> the patch you proposed which looks rather large and complicated?

That patch *is* an attempt to make it match ORC's behavior.  What
specifically looks complicated about it?

-- 
Josh