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 247C9C433EF for ; Thu, 5 May 2022 03:36:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241495AbiEEDkB (ORCPT ); Wed, 4 May 2022 23:40:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229999AbiEEDj4 (ORCPT ); Wed, 4 May 2022 23:39:56 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE37149934; Wed, 4 May 2022 20:36:17 -0700 (PDT) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Ktzq36K7SzfbDj; Thu, 5 May 2022 11:35:11 +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; Thu, 5 May 2022 11:36:16 +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; Thu, 5 May 2022 11:36:15 +0800 Message-ID: Date: Thu, 5 May 2022 11:36:12 +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 v4 22/37] arm64: kernel: Skip validation of kuser32.o Content-Language: en-US To: Peter Zijlstra CC: , , , , , , , , , , , , , , , References: <20220429094355.122389-1-chenzhongjin@huawei.com> <20220429094355.122389-23-chenzhongjin@huawei.com> From: Chen Zhongjin In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.108.67] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) 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 Peter, IIRC now the blacklist mechanisms all run on check stage, which after decoding, but the problem of kuser32.S happens in decoding stage. Other than that the assembly symbols in kuser32 is STT_NOTYPE and STACK_FRAME_NON_STANDARD will throw an error for this. OBJECT_FILES_NON_STANDARD works for the single file but as you said after LTO it's invalid. However STACK_FRAME_NON_STANDARD doesn't work for kuser32 case at all. Now my strategy for undecodable instructions is: show an error message and mark insn->ignore = true, but do not stop anything so decoding work can going on. To totally solve this my idea is that applying blacklist before decode. However for this part objtool doesn't have any insn or func info, so we should add a new blacklist just for this case... On 2022/4/29 19:05, Peter Zijlstra wrote: > On Fri, Apr 29, 2022 at 05:43:40PM +0800, Chen Zhongjin wrote: >> From: Raphael Gault >> >> kuser32 being used for compatibility, it contains a32 instructions >> which are not recognised by objtool when trying to analyse arm64 >> object files. Thus, we add an exception to skip validation on this >> particular file. >> >> Signed-off-by: Raphael Gault >> Signed-off-by: Julien Thierry >> Signed-off-by: Chen Zhongjin >> --- >> arch/arm64/kernel/Makefile | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile >> index 986837d7ec82..c4f01bfe79b4 100644 >> --- a/arch/arm64/kernel/Makefile >> +++ b/arch/arm64/kernel/Makefile >> @@ -41,6 +41,9 @@ obj-$(CONFIG_COMPAT) += sys32.o signal32.o \ >> sys_compat.o >> obj-$(CONFIG_COMPAT) += sigreturn32.o >> obj-$(CONFIG_KUSER_HELPERS) += kuser32.o >> + >> +OBJECT_FILES_NON_STANDARD_kuser32.o := y > > File based skipping is depricated in the face of LTO and other link > target based objtool runs. > > Please use function based blacklisting as per the previous patch. > > . 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 D1698C433EF for ; Thu, 5 May 2022 03:38:20 +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=WIwz8QKssKbdA7Uu4xhGTrJJx1hiIQGGpkR/QzYH9jU=; b=iOLVG48PBNLbpR krEmftnh4/7C1M99a4Rz6HTjz6X5wquhUexAjzfuTrLrhq0Kz4kb/ojfdQk7SgQz2Q4+i2OoNTqZk hFG6dXWzxHtQWhOTPxUXeCzv8Z3BjwRcm8Mp73YSJky5hAsbNZSnYiY8YMPk102FoSjiEpq78qcpF 4sZP/5ODxq2nKLcQzxFJWc97U+2wAPzE8ey9JYWh24EsBRkaF8l5o1zpmLuiuNfon3jGO5q4cw6Xf 178L0zd9h7sa+JdNMmhmy91322c75EHQ8Rje4h0hk1N4z2fEIP3yUsIMiCU3fa9ckGgFG2PAuIdXi o52Buo/pxZ435CGhjBzA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmSI2-00Dnlb-Ud; Thu, 05 May 2022 03:36:31 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmSHy-00Dni9-Vk for linux-arm-kernel@lists.infradead.org; Thu, 05 May 2022 03:36:28 +0000 Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Ktzq36K7SzfbDj; Thu, 5 May 2022 11:35:11 +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; Thu, 5 May 2022 11:36:16 +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; Thu, 5 May 2022 11:36:15 +0800 Message-ID: Date: Thu, 5 May 2022 11:36:12 +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 v4 22/37] arm64: kernel: Skip validation of kuser32.o Content-Language: en-US To: Peter Zijlstra CC: , , , , , , , , , , , , , , , References: <20220429094355.122389-1-chenzhongjin@huawei.com> <20220429094355.122389-23-chenzhongjin@huawei.com> From: Chen Zhongjin In-Reply-To: X-Originating-IP: [10.67.108.67] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) 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-20220504_203627_223001_0F136D78 X-CRM114-Status: GOOD ( 13.62 ) 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 Peter, IIRC now the blacklist mechanisms all run on check stage, which after decoding, but the problem of kuser32.S happens in decoding stage. Other than that the assembly symbols in kuser32 is STT_NOTYPE and STACK_FRAME_NON_STANDARD will throw an error for this. OBJECT_FILES_NON_STANDARD works for the single file but as you said after LTO it's invalid. However STACK_FRAME_NON_STANDARD doesn't work for kuser32 case at all. Now my strategy for undecodable instructions is: show an error message and mark insn->ignore = true, but do not stop anything so decoding work can going on. To totally solve this my idea is that applying blacklist before decode. However for this part objtool doesn't have any insn or func info, so we should add a new blacklist just for this case... On 2022/4/29 19:05, Peter Zijlstra wrote: > On Fri, Apr 29, 2022 at 05:43:40PM +0800, Chen Zhongjin wrote: >> From: Raphael Gault >> >> kuser32 being used for compatibility, it contains a32 instructions >> which are not recognised by objtool when trying to analyse arm64 >> object files. Thus, we add an exception to skip validation on this >> particular file. >> >> Signed-off-by: Raphael Gault >> Signed-off-by: Julien Thierry >> Signed-off-by: Chen Zhongjin >> --- >> arch/arm64/kernel/Makefile | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile >> index 986837d7ec82..c4f01bfe79b4 100644 >> --- a/arch/arm64/kernel/Makefile >> +++ b/arch/arm64/kernel/Makefile >> @@ -41,6 +41,9 @@ obj-$(CONFIG_COMPAT) += sys32.o signal32.o \ >> sys_compat.o >> obj-$(CONFIG_COMPAT) += sigreturn32.o >> obj-$(CONFIG_KUSER_HELPERS) += kuser32.o >> + >> +OBJECT_FILES_NON_STANDARD_kuser32.o := y > > File based skipping is depricated in the face of LTO and other link > target based objtool runs. > > Please use function based blacklisting as per the previous patch. > > . _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel