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 53922C77B73 for ; Wed, 12 Apr 2023 05:01:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229572AbjDLFB0 (ORCPT ); Wed, 12 Apr 2023 01:01:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbjDLFBX (ORCPT ); Wed, 12 Apr 2023 01:01:23 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F61F2D66; Tue, 11 Apr 2023 22:01:10 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BF15A62DFE; Wed, 12 Apr 2023 05:01:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C868C433EF; Wed, 12 Apr 2023 05:01:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681275669; bh=G34y1UTsgrhc2za6yW+gBMsV0zsh6UXi4C/xqhhs5j0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BHVEiwfcg0/EU4oYhR236DrW8YUs8OMXWN7A4yezlr2i/5mCguZk+rTijhhH8CCpp zNIL7tsecA1Wso4RBu+fCrewkQIXm6L5qUfWHKn2SYadgBhxHQ7VG2ogeJSllt+S6w W3Sve0L8FZGJkx4b/ikC/9kcdTQq/SRq64FoGehSxUScIGaISjL5oFcmcp29K1MW+Q 06xgo6kFG+rQaylJc2koHBWMEenS5ISHD9uDkYFgb4R3fCSp7NbJmGeEzCsmEAOFTE puRAA5r1pGwW9UppV+YSQKa0BFatH17WbDzxX7PjZya9RjDgGlPwQO0cHwvcfaE9Xs qrnh82/uSsgDw== Date: Tue, 11 Apr 2023 22:01:06 -0700 From: Josh Poimboeuf To: "Madhavan T. Venkataraman" 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 Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Message-ID: <20230412050106.7v4s3lalg43i6ciw@treble> References: <0337266cf19f4c98388e3f6d09f590d9de258dc7> <20230202074036.507249-1-madvenka@linux.microsoft.com> <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com> <20230412041752.i4raswvrnacnjjgy@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 11, 2023 at 11:48:21PM -0500, 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? 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). > > 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. -- Josh 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 CD66BC7619A for ; Wed, 12 Apr 2023 05:02:33 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UlXvV3Wa20uyZnoAXkuTnhvFQAbFn7bEv3FC4evuUGQ=; b=VoLzhP3oomICYs v9bQ7IedwcuzZKJcC7ns2WBINaIOeYrpPWIuUq6VR9syRA81K0VIPuI/wbf3qj/ux13S+qW9CfKe1 RfO5lHfK2ZrhwSraa8a35S6HKOglL3EKB1WlwCje1WpECj498u1K1vliA4HAtNVhkG7rKwGXc/zzd CD3BRx6ortIVWEAA0lBfDddbYouWyGVdJG3rLAc4ibjBO6xOfPIFG7i137gGctGXWjOnSA7et411n 7mD+sDsJEJqFFiivnTxdWBaqKLR3AiyY6y67aBu5GDNgUUkpnYfWsXT51gVIxoQZ2YS+M4AdEmeiW Z/+B1aJ39/4Xfq8rO7Hw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmSbZ-001nxM-2G; Wed, 12 Apr 2023 05:01:13 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pmSbW-001nwY-1J for linux-arm-kernel@lists.infradead.org; Wed, 12 Apr 2023 05:01:12 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BDEBD62DFA; Wed, 12 Apr 2023 05:01:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C868C433EF; Wed, 12 Apr 2023 05:01:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681275669; bh=G34y1UTsgrhc2za6yW+gBMsV0zsh6UXi4C/xqhhs5j0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BHVEiwfcg0/EU4oYhR236DrW8YUs8OMXWN7A4yezlr2i/5mCguZk+rTijhhH8CCpp zNIL7tsecA1Wso4RBu+fCrewkQIXm6L5qUfWHKn2SYadgBhxHQ7VG2ogeJSllt+S6w W3Sve0L8FZGJkx4b/ikC/9kcdTQq/SRq64FoGehSxUScIGaISjL5oFcmcp29K1MW+Q 06xgo6kFG+rQaylJc2koHBWMEenS5ISHD9uDkYFgb4R3fCSp7NbJmGeEzCsmEAOFTE puRAA5r1pGwW9UppV+YSQKa0BFatH17WbDzxX7PjZya9RjDgGlPwQO0cHwvcfaE9Xs qrnh82/uSsgDw== Date: Tue, 11 Apr 2023 22:01:06 -0700 From: Josh Poimboeuf To: "Madhavan T. Venkataraman" 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 Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Message-ID: <20230412050106.7v4s3lalg43i6ciw@treble> References: <0337266cf19f4c98388e3f6d09f590d9de258dc7> <20230202074036.507249-1-madvenka@linux.microsoft.com> <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com> <20230412041752.i4raswvrnacnjjgy@treble> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230411_220110_516792_B0164AE1 X-CRM114-Status: GOOD ( 29.62 ) 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 Tue, Apr 11, 2023 at 11:48:21PM -0500, 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? 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). > > 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. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel