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 B2F58C7619A for ; Wed, 12 Apr 2023 04:50:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229593AbjDLEu6 (ORCPT ); Wed, 12 Apr 2023 00:50:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229452AbjDLEuz (ORCPT ); Wed, 12 Apr 2023 00:50:55 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3DA5C3C31; Tue, 11 Apr 2023 21:50:54 -0700 (PDT) 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: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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. >>