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 5300DC433F5 for ; Tue, 24 May 2022 14:26:19 +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:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cyOMoNk+oZS76qeVPvDKOxPGPSqzbKZN/zK7vKwysRg=; b=juuFzHLHlurVNI Ht9H8dMPMPZsorkau3RhqAfRr0/cM069d7bbqD4UEBbvHt29SX9nh7UF1inRT18Ec20VeoenqBT73 VRmaQZ1o3Uzcr7mQOSpoMZzkAOikNZDW51fR0I7QSKspvJOdZhdOkU7NiY/0XalmHGKgByEu0Ja9H b79jtv+jHe9AWJAJfP1KT+1rggblnGr1HXgatamy+t9+CibR48Ykj7H+t4a+rOEWVCGEJ812cbus6 t8Uwi6kN8o8ZXe5MCLrpd0Hk46FJ7sCPKi5zPVwWVtg8Cxr1yzg4HlOo3cwutriKDA2bERUB9TM/U 0A0mhfASKlBr+cjk107g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntVT9-008F1R-Ar; Tue, 24 May 2022 14:25:07 +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 1ntVT5-008EzW-6p for linux-arm-kernel@lists.infradead.org; Tue, 24 May 2022 14:25:05 +0000 Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4L6xK967grzjX04; Tue, 24 May 2022 22:24:13 +0800 (CST) Received: from dggpemm500013.china.huawei.com (7.185.36.172) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 24 May 2022 22:24:56 +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; Tue, 24 May 2022 22:24:55 +0800 Message-ID: <061a4299-114f-96e0-86a4-6ab255778498@huawei.com> Date: Tue, 24 May 2022 22:24:55 +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 v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation Content-Language: en-US To: , , , , , , , , , , , , References: <20220524001637.1707472-1-madvenka@linux.microsoft.com> From: Chen Zhongjin In-Reply-To: <20220524001637.1707472-1-madvenka@linux.microsoft.com> 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220524_072503_543308_2BCF15D9 X-CRM114-Status: UNSURE ( 8.87 ) X-CRM114-Notice: Please train this message. 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 Madvenka, I have a brief look at your patch and the idea that using CFA metadata to validate FP is reasonable to me. And I found a problem when I used 'pv dump' to check the orc value and I replied your commit 11/20 for that. I think it's not necessary that you rewrite the arm64 decoder(there is already a decoder in my patch) and insn check(objtool check can just make it) by yourself. Especially it is too duplicated to have two check in objtool. For me it's also a trouble that objtool runs too much unnecessary work. I advise that we should move some check for x86 as arch specific and refactor the cmdline options, they doesn't turn off everything perfectly now. Other than that I have an advise: We only use orc for reliable stacktrace and normal FP unwind doesn't depends on it. Should we only load these data for livepatch (or other scenario needs reliable stacktrace)? It can save the memory and time consuming for kernel. That's all. And if you don't mind, can I incorporate some commit into my set? Appreciate for it. Best, Chen _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel