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 8BFC9C43334 for ; Fri, 24 Jun 2022 22:15:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231769AbiFXWPg (ORCPT ); Fri, 24 Jun 2022 18:15:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229873AbiFXWPe (ORCPT ); Fri, 24 Jun 2022 18:15:34 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 20C138858F; Fri, 24 Jun 2022 15:15:33 -0700 (PDT) Received: from [192.168.254.32] (unknown [47.189.24.195]) by linux.microsoft.com (Postfix) with ESMTPSA id 0682620C7943; Fri, 24 Jun 2022 15:15:31 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0682620C7943 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1656108932; bh=hAvoj8jjZe3egtsndVQDOBocwQja3xej+5CD+Ld/09U=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=AIM3UBtfsqGjo5ImQw5cmqOAgxzr7cv8le3OqzCp3cdmlFqMIbKU99rUajFZ5jc0k 2OV8HIVuJSX5C3BqpvV4foKGinW2GXmWmyoOFI9UwrnCAC+BlzFDL0KdXfqN1hZJhZ EfnKBYEr12ZFYR4Uzb75eook4yQ4dvvKKYNCzFxk= Message-ID: <3180d0d3-2a92-13cd-2342-39b8400e3306@linux.microsoft.com> Date: Fri, 24 Jun 2022 17:15:31 -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: [PATCH v15 0/6] arm64: Reorganize the unwinder and implement stack trace reliability checks Content-Language: en-US To: Mark Brown , Will Deacon Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220617210717.27126-1-madvenka@linux.microsoft.com> <20220623173224.GB16966@willie-the-truck> From: "Madhavan T. Venkataraman" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/24/22 06:42, Mark Brown wrote: > On Thu, Jun 23, 2022 at 06:32:24PM +0100, Will Deacon wrote: >> On Fri, Jun 17, 2022 at 04:07:11PM -0500, madvenka@linux.microsoft.com wrote: > >>> as HAVE_RELIABLE_STACKTRACE depends on STACK_VALIDATION which is not present >>> yet. This patch will be added in the future once Objtool is enhanced to >>> provide stack validation in some form. > >> Given that it's not at all obvious that we're going to end up using objtool >> for arm64, does this patch series gain us anything in isolation? > > Having the reliability information seems like it should be useful in > general even without doing live patching - we can use it to annotate > stack traces to warn people about anything that might be suspect in > there. For live patching it's probably something we'll want regardless > of the use of objtool, it's one more robustness check which always > helps. Hi Mark, Will, Your comments got me to thinking about the Objtool patch series I have sent earlier. Since the general feeling is that Objtool is unlikely to be our path to livepatch on ARM64, I think that I can implement what I want in a simpler way as a kernel-only solution. The kernel already has a decoder. I don't need to provide one. In the kernel-only solution, I don't have to worry about relocations, alternatives, etc, etc. The number of patches would be about half of the original series with simpler code in many of the patches. The amount of memory consumed by the CFI entries will most likely be just a fraction of the original series. I will investigate this. If it works and turns out to be a lot simpler, I will send this as v3 of the livepatch patch series. Also, if this works, we can replace the various reliability checks with just a single fp validation check in the unwinder. Thanks for the input. Madhavan 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 04F9EC433EF for ; Fri, 24 Jun 2022 22:16:40 +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=xU7Jbu1feqll0KwmrsZ4bfSgT0F/uz3shxprN3hLVQM=; b=VtczGqQrplkQFk YHD2T6McBuUi3S1OKBQJs6t9ROVa7ZJL4ZGFDm4ogA7fPozudmcfgXAq6StrOzng19vfbjLkQttoj /MWZaRvt2jUhaP3rJ/mchiDgEX4MQRVuFN/Qg4Ajs5Kz6HQCxI+fl5x4jY3QEJ9QT9U9BHEIrZ0+n pDdPjuAMCQQ0ujF/gCYdqtNvANPMPYIRFHA7BLaX8nBjSGD4/o80/R+ExknKZSw6gaSRVmR22mIOV KWtD5+731cJVSubigrbfLcKQI7ypEo60uCGd3rzdtEaoQhu8UD4Xx/o5UKEmCXf3lkcBhDYJO35m4 52INuL7SRnzcfyrXKr/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o4raW-003yLS-2d; Fri, 24 Jun 2022 22:15:40 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o4raS-003yKX-St for linux-arm-kernel@lists.infradead.org; Fri, 24 Jun 2022 22:15:38 +0000 Received: from [192.168.254.32] (unknown [47.189.24.195]) by linux.microsoft.com (Postfix) with ESMTPSA id 0682620C7943; Fri, 24 Jun 2022 15:15:31 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0682620C7943 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1656108932; bh=hAvoj8jjZe3egtsndVQDOBocwQja3xej+5CD+Ld/09U=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=AIM3UBtfsqGjo5ImQw5cmqOAgxzr7cv8le3OqzCp3cdmlFqMIbKU99rUajFZ5jc0k 2OV8HIVuJSX5C3BqpvV4foKGinW2GXmWmyoOFI9UwrnCAC+BlzFDL0KdXfqN1hZJhZ EfnKBYEr12ZFYR4Uzb75eook4yQ4dvvKKYNCzFxk= Message-ID: <3180d0d3-2a92-13cd-2342-39b8400e3306@linux.microsoft.com> Date: Fri, 24 Jun 2022 17:15:31 -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: [PATCH v15 0/6] arm64: Reorganize the unwinder and implement stack trace reliability checks Content-Language: en-US To: Mark Brown , Will Deacon Cc: mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220617210717.27126-1-madvenka@linux.microsoft.com> <20220623173224.GB16966@willie-the-truck> From: "Madhavan T. Venkataraman" In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220624_151536_995437_D0F79BC2 X-CRM114-Status: GOOD ( 18.60 ) 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 6/24/22 06:42, Mark Brown wrote: > On Thu, Jun 23, 2022 at 06:32:24PM +0100, Will Deacon wrote: >> On Fri, Jun 17, 2022 at 04:07:11PM -0500, madvenka@linux.microsoft.com wrote: > >>> as HAVE_RELIABLE_STACKTRACE depends on STACK_VALIDATION which is not present >>> yet. This patch will be added in the future once Objtool is enhanced to >>> provide stack validation in some form. > >> Given that it's not at all obvious that we're going to end up using objtool >> for arm64, does this patch series gain us anything in isolation? > > Having the reliability information seems like it should be useful in > general even without doing live patching - we can use it to annotate > stack traces to warn people about anything that might be suspect in > there. For live patching it's probably something we'll want regardless > of the use of objtool, it's one more robustness check which always > helps. Hi Mark, Will, Your comments got me to thinking about the Objtool patch series I have sent earlier. Since the general feeling is that Objtool is unlikely to be our path to livepatch on ARM64, I think that I can implement what I want in a simpler way as a kernel-only solution. The kernel already has a decoder. I don't need to provide one. In the kernel-only solution, I don't have to worry about relocations, alternatives, etc, etc. The number of patches would be about half of the original series with simpler code in many of the patches. The amount of memory consumed by the CFI entries will most likely be just a fraction of the original series. I will investigate this. If it works and turns out to be a lot simpler, I will send this as v3 of the livepatch patch series. Also, if this works, we can replace the various reliability checks with just a single fp validation check in the unwinder. Thanks for the input. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel