Received-SPF: pass (google.com: domain of linux-kernel+bounces-97926-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: David Laight <David.Laight@ACULAB.COM>
To: 'Russell King' <linux@armlinux.org.uk>, Josh Poimboeuf
	<jpoimboe@kernel.org>
CC: Jiangfeng Xiao <xiaojiangfeng@huawei.com>, Kees Cook
	<keescook@chromium.org>, Jann Horn <jannh@google.com>,
	"gustavoars@kernel.org" <gustavoars@kernel.org>, "akpm@linux-foundation.org"
	<akpm@linux-foundation.org>, "peterz@infradead.org" <peterz@infradead.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-hardening@vger.kernel.org" <linux-hardening@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>, "nixiaoming@huawei.com"
	<nixiaoming@huawei.com>, "kepler.chenxin@huawei.com"
	<kepler.chenxin@huawei.com>, "wangbing6@huawei.com" <wangbing6@huawei.com>,
	"wangfangpeng1@huawei.com" <wangfangpeng1@huawei.com>,
	"douzhaolei@huawei.com" <douzhaolei@huawei.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>, Ard Biesheuvel <ardb@kernel.org>
Subject: RE: [PATCH] usercopy: delete __noreturn from usercopy_abort
Thread-Topic: [PATCH] usercopy: delete __noreturn from usercopy_abort
Thread-Index: AQHab6wYEHIoKEvMpEWW5WbAwswgILEvgkBg
Date: Sat, 9 Mar 2024 14:58:25 +0000
Message-ID: <15437f635ba94224b6ed808bd6f42065@AcuMS.aculab.com>
References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com>
 <CAG48ez1h9X7Qv-5OR6hAhwnSOng6_PSXBaR6cT7xrk2Wzu39Yg@mail.gmail.com>
 <202403040938.D770633@keescook>
 <77bb0d81-f496-7726-9495-57088a4c0bfc@huawei.com>
 <202403050129.5B72ACAA0D@keescook>
 <b274b545-9439-7ff8-e3ed-604a9ac81f65@huawei.com>
 <20240305175846.qnyiru7uaa7itqba@treble>
 <Zeg8wRYFemMjcCxG@shell.armlinux.org.uk>
In-Reply-To: <Zeg8wRYFemMjcCxG@shell.armlinux.org.uk>
Accept-Language: en-GB, en-US
Precedence: bulk
MIME-Version: 1.0
Content-Language: en-US
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

From: Russell King
> Sent: 06 March 2024 09:52
>=20
> 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.
>=20
> I suppose this can only happen in __noreturn functions because that
> can be:
>=20
> foo:
> ..
> =09bl=09bar
> .. end of function and thus next function ...
>=20
> which results in LR pointing into the next function.
>=20
> 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?

=09David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1=
PT, UK
Registration No: 1397386 (Wales)