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 89971C77B61 for ; Thu, 13 Apr 2023 15:00:29 +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=JaTZMbW7KCiUD3SCejxQC4le3vEXFVXTeDIBTKYwC78=; b=wGWf/IbVBSRpy0 nN2b9tGU/0PjKkhA/V+CDmSYW5kNq0yyQc2k9c52MNrNFjOyZIe3jx3yLADGoCGQSAYMC5iGneAqQ ZRg2JNeUmOiaEw/1DwqbvGcFSXOv6dA29wNSdalQGChAEbCLDUL18qIgMR6sU5WI0aTcvZmpDvN3j rfrTnhUTsUF/XS3eah5graP93Sa3Awx4b4pRNxixkysymrYfv/nELuR7y2tENR1M3Ae0vAKM5ZMH/ CSxN/GDFDLdANbemlke1ERvIVxd7Q7t3bpNECJ16QWQVdZ9lxs9aQqHabXSOIGK4qpcl0/7pIBZqM 8Ubdo9s8+i+2/JuCv+iw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmyQD-006SyN-0k; Thu, 13 Apr 2023 14:59:37 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmyQA-006SxT-1y for linux-arm-kernel@lists.infradead.org; Thu, 13 Apr 2023 14:59:35 +0000 Received: from [192.168.254.32] (unknown [47.189.246.67]) by linux.microsoft.com (Postfix) with ESMTPSA id E1B9B2179255; Thu, 13 Apr 2023 07:59:31 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E1B9B2179255 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1681397972; bh=9dCYOGSbIYbfYYbmLvUJ5TG/nk29LN5wquzmrRZ81Uc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=bA/8X41O3YYQ46GMlQH62h1w4H8PuSCT37utR845/hQjryig4kFiPnGIW159LT26B HrpaV3RQ6IMpRJZMO6SnESlK1cfJU4GmT4+Bp+p2ur6l+JBifq6qTfv4+alQUyv+S3 NnIm9HRzeB+GKC4v2iOg5JvPiJLd4ayY2Jw6276s= Message-ID: Date: Thu, 13 Apr 2023 09:59:31 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation To: Josh Poimboeuf Cc: Mark Rutland , jpoimboe@redhat.com, peterz@infradead.org, chenzhongjin@huawei.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: <0337266cf19f4c98388e3f6d09f590d9de258dc7> <20230202074036.507249-1-madvenka@linux.microsoft.com> <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com> <20230412041752.i4raswvrnacnjjgy@treble> <20230412050106.7v4s3lalg43i6ciw@treble> <20230412155221.2l2mqsyothseymeq@treble> Content-Language: en-US From: "Madhavan T. Venkataraman" In-Reply-To: <20230412155221.2l2mqsyothseymeq@treble> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230413_075934_676561_F7D582B6 X-CRM114-Status: GOOD ( 15.91 ) 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 4/12/23 10:52, Josh Poimboeuf wrote: > On Wed, Apr 12, 2023 at 09:50:23AM -0500, Madhavan T. Venkataraman wrote: >>>> I read through the SFrame spec file briefly. It looks like I can easily adapt my >>>> version 1 of the livepatch patchset which was based on DWARF to SFrame. If the compiler >>>> folks agree to properly support and maintain SFrame, then I could send the next version >>>> of the patchset based on SFrame. >>>> >>>> But I kinda need a clear path forward before I implement anything. I request the arm64 >>>> folks to comment on the above approach. Would it be useful to initiate an email discussion >>>> with the compiler folks on what they plan to do to support SFrame? Or, should this all >>>> happen face to face in some forum like LPC? >>> >>> SFrame is basically a simplified version of DWARF unwind, using it as an >>> input to objtool is going to have the same issues I mentioned below (and >>> as was discussed with your v1). >>> >> >> Yes. It is a much simplified version of DWARF. So, I am hoping that the compiler folks >> can provide the feature with a reliability guarantee. DWARF is too complex. > > I don't see what the complexity (or lack thereof) of the unwinding data > format has to do with it. The unreliability comes from the underlying > data source, not the formatting of the data. > What I meant is - if SFrame is implemented by simply extracting unwind info from DWARF data and placing it in a separate section (as it is probably implemented now), then what you say is totally true. But if the compiler folks agree to make SFrame reliable, then either they have to make DWARF reliable. Or, they have to implement SFrame as a separate feature and make it reliable. The former is tough to do as DWARF has a lot of complexity. The latter is a lot easier to do. Sorry if that was not clear. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel