Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp3546507ioo; Mon, 30 May 2022 04:42:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8uNbcIUuMYQw08MLSfFWI9Y9Mh9EcebEho3vZGNeYrByWmS0mItYB4liwZ5Ag383UM2vk X-Received: by 2002:a17:906:c1ca:b0:6fe:9c2a:8106 with SMTP id bw10-20020a170906c1ca00b006fe9c2a8106mr47011090ejb.383.1653910946861; Mon, 30 May 2022 04:42:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653910946; cv=none; d=google.com; s=arc-20160816; b=cemXNIqwWPBKpX7IQgz1lB6K/c+1YUfqfOCR6T16hix8izuWL/EZ90IyIfeW72Lge5 INb/TDqnw9ckAaxDBexyIwLrlsJeQ5rsSb3kXdaoGTKsZoImengnXCFdkdK+JWiqWmDm OWgycq9UsKfZghFqn5L3P+4hAIlVSqAq3sdvJDNlwgZzXSGjyuSH3+9O2u07REoeWYcL zw0tsq6vaK8tJ7BcQZHEGz1re58GB17V5Wd/3jq9vpzbVssnhenBuC1wim7/5AUx7cLm hDmDObiCyraktCsGz2ANfVgAn7WZXWpCNmlmRywRbChbckkl/InOn8RVHln8k2HpcXDe ajpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:to:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature:dkim-filter; bh=pdXpNwS5tSP0aX9qQcLAkwzcKjd/aClB5ao6pff2Q0I=; b=M6mEqo4UTCJ67889j6o+XNMUJEjioeOdl3w6TS9KERwYkdiTZBeRqFcqHmiNDjEHWt XvG3Mtxz/o0tcaEI4sa3jE7wvff/iMD+hx9J5MsevXTMxBbxED2EmAiHTf9/6P8olXKs GfoSontOFjGPUntJxRU5Y8FlVh4XofcPZI+FjTrjRMz7SlYzSxCui4Hh5Fs4ck0MS7sn HE3I0JZFQP7Xe03X1zZxhXM8KCh7hnv8vdHIpMJb50DWJTmIDxweMeeNlCOKERXHehRk sTbDbDBlMjNnWCY14e6WspBXi18OGheEEIb5SME5fS99IhLVkJcOBMRQPMug1sYaGiIT LC7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=YVWltzDq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q36-20020a05640224a400b0042dbb8886fesi5959531eda.59.2022.05.30.04.42.00; Mon, 30 May 2022 04:42:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=YVWltzDq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231148AbiE2PaN (ORCPT + 99 others); Sun, 29 May 2022 11:30:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38592 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229844AbiE2PaL (ORCPT ); Sun, 29 May 2022 11:30:11 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id BD4CA3FBC4; Sun, 29 May 2022 08:30:10 -0700 (PDT) Received: from [192.168.254.32] (unknown [47.189.24.195]) by linux.microsoft.com (Postfix) with ESMTPSA id 9F1F920BA5B8; Sun, 29 May 2022 08:30:09 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9F1F920BA5B8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1653838210; bh=pdXpNwS5tSP0aX9qQcLAkwzcKjd/aClB5ao6pff2Q0I=; h=Date:Subject:To:References:From:In-Reply-To:From; b=YVWltzDq0xT0imdsQDszhe82aLx+DIJ9wUPZO0fPx/c5zvPMypEHnW+dssG+ibi8f qGNWYSYabf5K2UJUCYCe1xoq0woOn7HcRoGubaict2eIBavQLQeM8KfyvCzrY9VFSv wqygMdB/fvltIODqmhU58Be0YbwNfkt4BsYsn7l8= Message-ID: <2b8d8fbe-e596-91bf-a63b-938c9ff4140a@linux.microsoft.com> Date: Sun, 29 May 2022 10:30:08 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [RFC PATCH v2 00/20] arm64: livepatch: Use ORC for dynamic frame pointer validation Content-Language: en-US To: Chen Zhongjin , jpoimboe@redhat.com, peterz@infradead.org, mark.rutland@arm.com, broonie@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220524001637.1707472-1-madvenka@linux.microsoft.com> <061a4299-114f-96e0-86a4-6ab255778498@huawei.com> From: "Madhavan T. Venkataraman" In-Reply-To: <061a4299-114f-96e0-86a4-6ab255778498@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-21.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for taking the time to review my patches. On 5/24/22 09:24, Chen Zhongjin wrote: > 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 have responded to that comment in another email. Please take a look. > 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. > This is a fair point. I will think about this a little bit and respond to this in a separate email. > 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. > So, Josh has done what you have mentioned. He has reorganized all of that code. I am working on syncing up to his changes. I will send out version 3. > 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. > Yes. For ARM64, that is what I am trying to do. STACK_VALIDATION is optional and it is off by default. It needs to be turned on only if reliable stack trace is required. > That's all. And if you don't mind, can I incorporate some commit into my set? > Appreciate for it. > Please feel free to use any and all of my code. I am also looking at merging our two decoders so that there is only one decoder. I need to think about this a little bit. So, stay tuned. Thanks! Madhavan