From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4FCD1C54798 for ; Sat, 9 Mar 2024 14:58:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 332C46B0071; Sat, 9 Mar 2024 09:58:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2E2786B0072; Sat, 9 Mar 2024 09:58:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AAC06B0074; Sat, 9 Mar 2024 09:58:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 096266B0071 for ; Sat, 9 Mar 2024 09:58:20 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CA8851C07F9 for ; Sat, 9 Mar 2024 14:58:19 +0000 (UTC) X-FDA: 81877806318.26.380EA09 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by imf21.hostedemail.com (Postfix) with ESMTP id 1BC611C0009 for ; Sat, 9 Mar 2024 14:58:15 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf21.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709996297; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/X7H1ggJXyw8oZM2tEuo8CdkdavfIrnwt00+d/TQK+U=; b=2S8FNZOM+0OJBK6cwZA0kd35A3v64xWFkptA8iYj3+PioOC6ciGJZ6AWgpMoBFCU1S1dXe Y+3payCY/0pVeYdKxbrm+oGaX6z4W4EQQO4DTEYMDDQNi9OV/Hw6dkZHllC5l1XNMwgf5R WQBQZBNVgh5mXewAES4WBeyHlKWaaOQ= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf21.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709996297; a=rsa-sha256; cv=none; b=UVqjPKx7A4PlnmBjS6dZJg6lrsHkFyzQtfVnn9dKpBQUhFTROiUWK7Ab9qwNJMt2pHnQA3 WmIagpr2204kvzAXQrLnpmSJbLKriYTKR0ufek7e3oXkSoJ5rmCtt8TAWTnxUTustx02IC aoctvP1WFTM4/0kq1+8xFZXxfAj5M98= Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-156-mu8viMgRPXKNX4dY6V6FnA-1; Sat, 09 Mar 2024 14:58:11 +0000 X-MC-Unique: mu8viMgRPXKNX4dY6V6FnA-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Sat, 9 Mar 2024 14:58:25 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Sat, 9 Mar 2024 14:58:25 +0000 From: David Laight To: 'Russell King' , Josh Poimboeuf CC: Jiangfeng Xiao , Kees Cook , Jann Horn , "gustavoars@kernel.org" , "akpm@linux-foundation.org" , "peterz@infradead.org" , "dave.hansen@linux.intel.com" , "kirill.shutemov@linux.intel.com" , "linux-kernel@vger.kernel.org" , "linux-hardening@vger.kernel.org" , "linux-mm@kvack.org" , "nixiaoming@huawei.com" , "kepler.chenxin@huawei.com" , "wangbing6@huawei.com" , "wangfangpeng1@huawei.com" , "douzhaolei@huawei.com" , "linux-arm-kernel@lists.infradead.org" , Ard Biesheuvel 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> <202403040938.D770633@keescook> <77bb0d81-f496-7726-9495-57088a4c0bfc@huawei.com> <202403050129.5B72ACAA0D@keescook> <20240305175846.qnyiru7uaa7itqba@treble> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 1BC611C0009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: y59ud8qbeqfp7eys1sd3aa5rmqhux4mp X-HE-Tag: 1709996295-594513 X-HE-Meta: U2FsdGVkX19Sy1ErVD9LM3eCQflfRlsqPA9LGp93eNg35qT77raBoSe8CDPIbHiPuUaYGti/evhUKESewBBySQ81Y2laNSHbP2JF0t+WSGXptgYgGIaXiIzSWEAe5J4f70+JpfqRVx0Iog6JP5aHSnyxogfOsc4L6B9vFhLBop8m5N9tcNt7QCAGu1liwNnRVzFX16QFfCoNGLsmVjxjKJoWNUcT5jyTFXOPCbWmMW3CGHjOWWh/vcc3YOMTsN0xRqpYxlYXphI1EDzTIBFI0joUE64TRYQs6OIuChCcmdb4g85tx11LPja6DD93QrbYUP5946/cg8z6XGSAEZa/6Z0529kkX5yhvsowl0pwGeDh6J1JcCdTZ9T8Uja0rwZs3qD4K51BFL3UTJkJZntHQgfvTt6/RI0xEW1pGL4zkOK7J+rUgp+s8xyFyUlL+fKT6av+gm8QU7yXQ/ghXzYZFFpjdnn8HgKoVRNhYVcq3QpC4sTex2Hg2Xq/jEfR9Wb5tDC4yXlGexpeOnmEOL5APzuy8DGedPEtwPrKlDfRyoOLyuGnDHgEHWMgRmiCd4F7RRZG+/Kl1QLTa5slxBSC+dsar5+361nM//3gRJRhRNCi6JvRt+yXpDTkqPnjGja2paQ+2ys8cdlNQQqmyR8VsMZLLxYKkxawXXHMPYNa8Z51Pz9/yfJ+4GlaQ6uydo0L9BJGJhBTUsA1BRYo6G1TIOqXKZ0IM4tQ0xfoYW7yRKMPpNxUqbR9IT9BUxOE4uob7gV6iWEzxvYGalyLCI86YDAt8ZSFYAJe3qUoXNRHkDM6M9jxIhO6SIt0dnN4kxkhwBCBUpkxlSDTPyRM4KDrMzuql5nnnfgtjhr3eMbbULBTk7QSriiqIfeKM5la9cCkQHtnt6qB2iX/xVOltisuMBCgKjlcjekwxWkjb4/IjMiGuDIkKgZUVg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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)