[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15437f635ba94224b6ed808bd6f42065@AcuMS.aculab.com>
Date: Sat, 9 Mar 2024 14:58:25 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Russell King' <linux@...linux.org.uk>, Josh Poimboeuf
<jpoimboe@...nel.org>
CC: Jiangfeng Xiao <xiaojiangfeng@...wei.com>, Kees Cook
<keescook@...omium.org>, Jann Horn <jannh@...gle.com>,
"gustavoars@...nel.org" <gustavoars@...nel.org>, "akpm@...ux-foundation.org"
<akpm@...ux-foundation.org>, "peterz@...radead.org" <peterz@...radead.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "nixiaoming@...wei.com"
<nixiaoming@...wei.com>, "kepler.chenxin@...wei.com"
<kepler.chenxin@...wei.com>, "wangbing6@...wei.com" <wangbing6@...wei.com>,
"wangfangpeng1@...wei.com" <wangfangpeng1@...wei.com>,
"douzhaolei@...wei.com" <douzhaolei@...wei.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, Ard Biesheuvel <ardb@...nel.org>
Subject: RE: [PATCH] usercopy: delete __noreturn from usercopy_abort
From: Russell King
> Sent: 06 March 2024 09:52
>
> 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?
Is it even possible to always reliably get a stack trace from
a no-return function on a cpu that uses a 'lr'?
If the function doesn't return then the compiler need not save
'lr' on stack and can still use it as a temporary register.
Without a valid 'lr' I think all you can do is search the stack
for a likely code address?
Am I missing something?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists