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 03537C433F5 for ; Fri, 8 Apr 2022 09:26:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232518AbiDHJ2e (ORCPT ); Fri, 8 Apr 2022 05:28:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231939AbiDHJ2T (ORCPT ); Fri, 8 Apr 2022 05:28:19 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A30208CD84 for ; Fri, 8 Apr 2022 02:26:15 -0700 (PDT) Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KZXrW3HKMzgYNK; Fri, 8 Apr 2022 17:24:27 +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.2308.21; Fri, 8 Apr 2022 17:26:04 +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.2308.21; Fri, 8 Apr 2022 17:26:12 +0800 Message-ID: Date: Fri, 8 Apr 2022 17:25:59 +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 From: Chen Zhongjin Subject: Re: [RFC PATCH v3 13/13] objtool: arm64: Enable stack validation for arm64 To: Peter Zijlstra CC: , , , , , , , , , References: <20220407120141.43801-1-chenzhongjin@huawei.com> <20220407120141.43801-14-chenzhongjin@huawei.com> <20220407121919.GK2731@worktop.programming.kicks-ass.net> Content-Language: en-US In-Reply-To: <20220407121919.GK2731@worktop.programming.kicks-ass.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.108.67] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) 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, You are right that Julien had tried to use gcc plugin to fix this but refused by Ard. With jump tables objtool will give some sibling call errors because we can't detect jump table correctly on arm64. Then in the v2 patch they gave a conclusion that it is acceptable to close jump table. Now we still have some problems on arm64. The todo list includes: - BRK insns are decoded as INSN_BUG and then marked as dead_end, which makes objtool stop checking and cause unreachable error. - Some functions need to be annotated by UNWIND micro or marked as noreturn. - arm64 and x86 share the code for check.c and it can make some problem. Now I found some errors about __ex_table which is related to alternative entry search code for x86 in special.c. - Some *.S file still contain data inside text section which cannot be excluded or decoded such as head.S. Also, we have a assembly file kuser32.S which reporting undecodable error. Now I'm trying to fix these problems with minimum change on arm64 architecture and objtool code. To be honest, objtool check grows to a huge x86 wool ball now and make migration a bit difficult. Josh mentions there will be a refectoring for objtool features and maybe we can separatedly support features on different arches which will make things easier. Also, Madhaven has commited a new patch for stack validation. It's seems an available approch that using DWARF to make stack validation so that we don't need to adapt to different architectures. I'm checking the code and planning to help to test it. Anyway, besides stack validation I think it's still valuable to migrate objtool on arm64. So let things going on and if you have any advise or help I'll be vary appriciate for that. Thanks for your time! On 2022/4/7 20:19, Peter Zijlstra wrote: > IIRC this is a sore spot for the whole endeavour..