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 647B2C7619A for ; Wed, 12 Apr 2023 04:51:59 +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:References:Cc:To:From: 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=+CaRy4PAYS4CCjwcu0h/btHRRHznKer1nhHDvtiNCmk=; b=qGjSWn7CDbRiSU j8/DXxSiG7DKp+qu04NKnUzPs+K6v5XCD5y9E2NVW2xKJYi/pQn2EzLGKkT0K8KEcLCSSwM2eCaAp JSnm4EvgO9cX/bnzqP0bXdXnt8IwWSNrQbgyrOOACFkzWUqRENNnRshUHeDH1oHFeZvKX8zVVMTM0 7M1fvb7VJfsoM0AEEJvNdDh1ky5ybvkCRtwBTH8AHVuaKdqnQrGj/LtoBmVSzkBY50BMqv1nvBPoE HoYlSAzbeXVuaGhojECA8+kvEfWlg0MGntgyjIkk+DCVWgN7+pwRTnktkZb9/Da49ZTct4WEVdhW6 oyNyVym/VDtdDwe8NNfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmSRe-001n5z-06; Wed, 12 Apr 2023 04:50:58 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmSRa-001n5B-0i for linux-arm-kernel@lists.infradead.org; Wed, 12 Apr 2023 04:50:55 +0000 Received: from [192.168.254.32] (unknown [47.189.246.67]) by linux.microsoft.com (Postfix) with ESMTPSA id F231D21779AE; Tue, 11 Apr 2023 21:50:52 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com F231D21779AE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1681275053; bh=irme9tjLIGSNXVQJQv9HwipL1iU0htwwfKVdz27MR0w=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=gut4QOYuQCPjH9mjktK+7AnzzdGgS52GrQLgmSqiZuHvNJrV77Yn2DgYxegCHq+R6 z5Hr775PMCMj+UsmjRA/RAeDpjbZoxJ2Loba4XvuOZvT5D6Y1OJd49YjsQi4qlgsIr oORO/e9KHH1WKwxBGT2/OYHONBk6Hx25+e+YB2QM= Message-ID: <8b7b779b-6552-c637-9a84-4dbc95fd0c07@linux.microsoft.com> Date: Tue, 11 Apr 2023 23:50:51 -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 Content-Language: en-US From: "Madhavan T. Venkataraman" To: Josh Poimboeuf , Mark Rutland Cc: 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> In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230411_215054_310958_353CE69F X-CRM114-Status: GOOD ( 20.75 ) 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/11/23 23:48, Madhavan T. Venkataraman wrote: > > > On 4/11/23 23:17, Josh Poimboeuf wrote: >> On Tue, Apr 11, 2023 at 02:25:11PM +0100, Mark Rutland wrote: >>>> By your own argument, we cannot rely on the compiler as compiler implementations, >>>> optimization strategies, etc can change in ways that are incompatible with any >>>> livepatch implementation. >>> >>> That's not quite my argument. >>> >>> My argument is that if we assume some set of properties that compiler folk >>> never agreed to (and were never made aware of), then compiler folk are well >>> within their rights to change the compiler such that it doesn't provide those >>> properties, and it's very likely that such expectation will be broken. We've >>> seen that happen before (e.g. with jump tables). >>> >>> Consequently I think we should be working with compiler folk to agree upon some >>> solution, where compiler folk will actually try to maintain the properties we >>> depend upon (and e.g. they could have tests for). That sort of co-design has >>> worked well so far (e.g. with things like kCFI). >>> >>> Ideally we'd have people in the same room to have a discussion (e.g. at LPC). >> >> That was the goal of my talk at LPC last year: >> >> https://lpc.events/event/16/contributions/1392/ >> >> We discussed having the compiler annotate the tricky bits of control >> flow, mainly jump tables and noreturns. It's still on my TODO list to >> prototype that. >> >> Another alternative which has been suggested in the past by Indu and >> others is for objtool to use DWARF/sframe as an input to help guide it >> through the tricky bits. >> > > 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? > > Madhavan > Just to be clear. This is not to replace Objtool as it has other uses as well, not just reliable stack trace. I am trying to solve the reliable stack trace issue alone with SFrame. Madhavan >> That seems more fragile -- as Madhavan mentioned, GCC-generated DWARF >> has some reliability issues -- and also defeats some of the benefits of >> reverse-engineering in the first place (we've found many compiler bugs >> and other surprising kernel-compiler interactions over the years). >> >> Objtool's understanding of the control flow graph has been really >> valuable for reasons beyond live patching (e.g., noinstr and uaccess >> validation), it's definitely worth finding a way to make that more >> sustainable. >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel