From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 944B940852 for ; Sat, 9 Mar 2024 14:58:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.58.85.151 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709996303; cv=none; b=PfMekROO0J2X3+Ibbr6meqsk5ITXEQlws6XTvs9X6gMvCJOIaxJDM1t5Y3uvtxgHFzhjku/M3vAvB+Ade7sxa/vgXSUGsY3f+0xQPFoWiJr78JMogzBa6oRIykmunfGF5qDsAt5Ip40e3Q+7s4dXwZrfleTrRE/Zeu+AVe+QR7A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709996303; c=relaxed/simple; bh=/X7H1ggJXyw8oZM2tEuo8CdkdavfIrnwt00+d/TQK+U=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: MIME-Version:Content-Type; b=qnjdgGmlnh2jxbHYFoGEefmWgOhivoXyO97ax7UbnAP2S0VktPm8L8wm+3QJ/KaBMNjUYKZ56gLiH2bPGXiNluhpzw/Wf67AdSk11huolWPBmqmP6fviy1HFf4K4gPVGVQHVkz2BujJs3EDG2nbacyME07DaSUYV0vPUWpqyAHE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ACULAB.COM; spf=pass smtp.mailfrom=aculab.com; arc=none smtp.client-ip=185.58.85.151 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ACULAB.COM Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=aculab.com 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 Precedence: bulk X-Mailing-List: linux-hardening@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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) 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C04F1C54E41 for ; Sat, 9 Mar 2024 14:58:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0yLLt8hboHNgk0n0/FKFiEGo7kZLzdWb5+yyspV0QZQ=; b=yohq95pfbSVaZe 9w6+Z6O7snQxo6De3+yLwNZpBeS3qz4j3BTge7tAxs7jzBwCrJDNnCmiCHpEMeyODFzi5Yq+gmhR7 kNDt9k+33VDkFqvK5Hv9q8IElF3daH60h2WChhBOLwoRfPiZf54Zk/vR69BHvuWKM75vpUyy3Pw5O sTqBkCjmo093c/BhTJnfdBzBdJD8tZVtebgiBeyZeVKJFjn8CIAGl1o/j2oPKNZQyjfWj/n1AmWI7 gby+PxKiz4AFGZnp2ffQfmM63jPot+kD8nbnNKHhFpvVGEyja/jskGL0T1D1ocDhoe010RHLUeY6S m5HR55sgMkTHGgP7xhnw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1riy9V-0000000DZvU-087v; Sat, 09 Mar 2024 14:58:21 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.85.151]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1riy9R-0000000DZuc-2KdZ for linux-arm-kernel@lists.infradead.org; Sat, 09 Mar 2024 14:58:19 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240309_065817_890726_F8EAD565 X-CRM114-Status: GOOD ( 21.60 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel