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 A12C4C433EF for ; Fri, 6 May 2022 02:19:26 +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=LlK8dcaWSCq+xeIFXH9V+owmtZe9Uuz1u1ruWLW8RlA=; b=3fHCT0E5elcTaL zW8BDsajFN3OFQ8EIWq6USa0PnFpPUojsVGz+o87WhGqBCIpFMiY8fyfB7RWsPvgNdb5q5ufiluzr Q4Kt5Xl1BHGfndTkzxXaMXEXdErbKojNBU+OZSDpS2t+XACXLQ8aUzwAuOLrmtTCv+bkKYH5Nl/nX iK4waAc+HHo97dyToOwXqs24WuCldJOffa50qVfE+LkYBw4wXFUqLs3v9SKjoSwviJR/P3hBz5hnw 5mDK7RZBmiNNIMuQHOlKPrnGHInsg6oh+iPVaPYRUfkfOE8z2VYr368ZSnOeUAwwHNzgNjH7fDiYB mPcWde2PxaxEXt7HrzYQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmnXy-000xAp-CS; Fri, 06 May 2022 02:18:22 +0000 Received: from szxga08-in.huawei.com ([45.249.212.255]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmnXu-000x9E-1d for linux-arm-kernel@lists.infradead.org; Fri, 06 May 2022 02:18:20 +0000 Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KvZ2Z0Vtsz1JBmW; Fri, 6 May 2022 10:17:10 +0800 (CST) Received: from dggpemm500013.china.huawei.com (7.185.36.172) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 6 May 2022 10:18:15 +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; Fri, 6 May 2022 10:18:14 +0800 Message-ID: <51ce37b5-f527-9743-36d3-50247cb0939f@huawei.com> Date: Fri, 6 May 2022 10:18:10 +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: Mark Rutland , Peter Zijlstra CC: , , , , , , , , , , , , , , References: <20220429094355.122389-1-chenzhongjin@huawei.com> <20220429094355.122389-23-chenzhongjin@huawei.com> <20220505092448.GE2501@worktop.programming.kicks-ass.net> From: Chen Zhongjin In-Reply-To: X-Originating-IP: [10.67.108.67] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) 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-20220505_191818_505458_44747F29 X-CRM114-Status: GOOD ( 14.39 ) 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 On 2022/5/5 18:56, Mark Rutland wrote: > On Thu, May 05, 2022 at 11:24:48AM +0200, Peter Zijlstra wrote: >> On Thu, May 05, 2022 at 11:36:12AM +0800, Chen Zhongjin wrote: >>> 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... >> >> OK, so Mark explained that this is 32bit userspace (VDSO) code. >> >> And as such there's really no point in running objtool on it. Does all >> that live in it's own section? Should it? > > It's placed in .rodata by a linker script: > > * The 32-bit vdso + kuser code is placed in .rodata, between the `vdso32_start` > and `vdso32_end` symbols, as raw bytes (via .incbin). > See arch/arm64/kernel/vdso32-wrap.S. > > * The 64-bit vdso code is placed in .rodata, between the `vdso_start` > and `vdso32` symbols, as raw bytes (via .incbin). > See arch/arm64/kernel/vdso-wrap.S. > > The objects under arch/arm64/kernel/{vdso,vdso32}/ are all userspace objects, > and from userspace's PoV the existing secrtions within those objects are > correct, so I don't think those should change. > > How does x86 deal with its vdso objects? > > Thanks, > Mark. > . However for my build kuser32.o content is in .text and there is only `vdso` symbol in .rodata without `vdso32`. And for defconfig the CONFIG_KUSER_HELPERS=y is on. According to your description, it seems something wrong here? If all 32-bit asm is placed in .rodata it won't cause problem for objtool check. Thanks! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel