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 C6561C433EF for ; Mon, 18 Apr 2022 12:30:05 +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:In-Reply-To:From:References:CC:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=K7MAw0tOBry8+cyIiTvUjAEyUcs1HmBdQH1EbMhwzTQ=; b=NDdJkVpDNQiJ96 uZbI9pO7CKQ0Sr6n17r3yMAWuD1/ZhLqwoZ9IreNVZ+eSd5cxaMADa/rNFuC52gjAQhrb1KItCBUH S3nyjEZKFOAzhvOOBjBYOeuUH0o9Wwoh95ABTO+0o+WJzp1suCGBIL6OtyblSvRQyNQxFsJr8DNOb +a+eU5eEMAct7W+STF4GSViIP0eLgJyDyfGMdG5E939VRKPYwMn1CV+VSpUdSxqRqT3icpeqUh75g 8Lop2j+0MixKJljBbN2A3y6cpatI7zEU/5JSnuRT9k0DFL68+W4MTNVnCyqxaSYQr6CzV2w81ZSTG gtQEf/4v4WghPehBZJlw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngQUw-00GkFS-5s; Mon, 18 Apr 2022 12:28:54 +0000 Received: from szxga02-in.huawei.com ([45.249.212.188]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ngQUq-00GkA3-EW for linux-arm-kernel@lists.infradead.org; Mon, 18 Apr 2022 12:28:50 +0000 Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KhmSM06LKzhXYf; Mon, 18 Apr 2022 20:28:35 +0800 (CST) Received: from dggpemm500013.china.huawei.com (7.185.36.172) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 18 Apr 2022 20:28:36 +0800 Received: from [127.0.0.1] (10.67.108.67) by dggpemm500013.china.huawei.com (7.185.36.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 18 Apr 2022 20:28:36 +0800 Message-ID: <0abfa1af-81ec-9048-6f95-cf5dda295139@huawei.com> Date: Mon, 18 Apr 2022 20:28:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH v1 0/9] arm64: livepatch: Use DWARF Call Frame Information for frame pointer validation Content-Language: en-US To: Josh Poimboeuf CC: "Madhavan T. Venkataraman" , , , , , , , , , , , References: <95691cae4f4504f33d0fc9075541b1e7deefe96f> <20220407202518.19780-1-madvenka@linux.microsoft.com> <20220408002147.pk7clzruj6sawj7z@treble> <15a22f4b-f04a-15e1-8f54-5b3147d8df7d@linux.microsoft.com> <35c99466-9024-a7fd-9632-5d21b3e558f7@huawei.com> <20220416005609.3znhltjlhpg475ff@treble> From: Chen Zhongjin In-Reply-To: <20220416005609.3znhltjlhpg475ff@treble> X-Originating-IP: [10.67.108.67] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500013.china.huawei.com (7.185.36.172) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220418_052848_741574_22B75340 X-CRM114-Status: GOOD ( 12.44 ) 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 Hi Josh, IIUC, ORC on x86 can make reliable stack unwind for this scenario because objtool validates BP state. I'm thinking that on arm64 there's no guarantee that LR will be pushed onto stack. When we meet similar scenario on arm64, we should recover (LR, FP) on pt_regs and continue to unwind the stack. And this is reliable only after we validate (LR, FP). So should we track LR on arm64 additionally as track BP on x86? Or can we just treat (LR, FP) as a pair? because as I know they are always set up together. On 2022/4/16 8:56, Josh Poimboeuf wrote: > On Tue, Apr 12, 2022 at 04:32:22PM +0800, Chen Zhongjin wrote: >> By the way, I was thinking about a corner case, because arm64 CALL >> instruction won't push LR onto stack atomically as x86. Before push LR, FP >> to save frame there still can be some instructions such as bti, paciasp. If >> an irq happens here, the stack frame is not constructed so the FP unwinder >> will omit this function and provides a wrong stack trace to livepatch. >> >> It's just a guess and I have not built the test case. But I think it's a >> defect on arm64 that FP unwinder can't work properly on prologue and >> epilogue. Do you have any idea about this? > > x86 has similar issues with frame pointers, if for example preemption or > page fault exception occurs in a leaf function, or in a function > prologue or epilogue, before or after the frame pointer setup. > > This issue is solved by the "reliable" unwinder which detects > irqs/exceptions on the stack and reports the stack as unreliable. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00A55C433EF for ; Mon, 18 Apr 2022 12:43:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239569AbiDRMqM (ORCPT ); Mon, 18 Apr 2022 08:46:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239825AbiDRMiJ (ORCPT ); Mon, 18 Apr 2022 08:38:09 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 295A72409F; Mon, 18 Apr 2022 05:28:42 -0700 (PDT) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KhmSM06LKzhXYf; Mon, 18 Apr 2022 20:28:35 +0800 (CST) Received: from dggpemm500013.china.huawei.com (7.185.36.172) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 18 Apr 2022 20:28:36 +0800 Received: from [127.0.0.1] (10.67.108.67) by dggpemm500013.china.huawei.com (7.185.36.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 18 Apr 2022 20:28:36 +0800 Message-ID: <0abfa1af-81ec-9048-6f95-cf5dda295139@huawei.com> Date: Mon, 18 Apr 2022 20:28:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC PATCH v1 0/9] arm64: livepatch: Use DWARF Call Frame Information for frame pointer validation Content-Language: en-US To: Josh Poimboeuf CC: "Madhavan T. Venkataraman" , , , , , , , , , , , References: <95691cae4f4504f33d0fc9075541b1e7deefe96f> <20220407202518.19780-1-madvenka@linux.microsoft.com> <20220408002147.pk7clzruj6sawj7z@treble> <15a22f4b-f04a-15e1-8f54-5b3147d8df7d@linux.microsoft.com> <35c99466-9024-a7fd-9632-5d21b3e558f7@huawei.com> <20220416005609.3znhltjlhpg475ff@treble> From: Chen Zhongjin In-Reply-To: <20220416005609.3znhltjlhpg475ff@treble> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.108.67] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500013.china.huawei.com (7.185.36.172) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Josh, IIUC, ORC on x86 can make reliable stack unwind for this scenario because objtool validates BP state. I'm thinking that on arm64 there's no guarantee that LR will be pushed onto stack. When we meet similar scenario on arm64, we should recover (LR, FP) on pt_regs and continue to unwind the stack. And this is reliable only after we validate (LR, FP). So should we track LR on arm64 additionally as track BP on x86? Or can we just treat (LR, FP) as a pair? because as I know they are always set up together. On 2022/4/16 8:56, Josh Poimboeuf wrote: > On Tue, Apr 12, 2022 at 04:32:22PM +0800, Chen Zhongjin wrote: >> By the way, I was thinking about a corner case, because arm64 CALL >> instruction won't push LR onto stack atomically as x86. Before push LR, FP >> to save frame there still can be some instructions such as bti, paciasp. If >> an irq happens here, the stack frame is not constructed so the FP unwinder >> will omit this function and provides a wrong stack trace to livepatch. >> >> It's just a guess and I have not built the test case. But I think it's a >> defect on arm64 that FP unwinder can't work properly on prologue and >> epilogue. Do you have any idea about this? > > x86 has similar issues with frame pointers, if for example preemption or > page fault exception occurs in a leaf function, or in a function > prologue or epilogue, before or after the frame pointer setup. > > This issue is solved by the "reliable" unwinder which detects > irqs/exceptions on the stack and reports the stack as unreliable. >