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 CC103C77B6E for ; Wed, 12 Apr 2023 04:48:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229572AbjDLEs2 (ORCPT ); Wed, 12 Apr 2023 00:48:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229481AbjDLEsZ (ORCPT ); Wed, 12 Apr 2023 00:48:25 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 18F933C11; Tue, 11 Apr 2023 21:48:24 -0700 (PDT) Received: from [192.168.254.32] (unknown [47.189.246.67]) by linux.microsoft.com (Postfix) with ESMTPSA id 9F03221779AC; Tue, 11 Apr 2023 21:48:22 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9F03221779AC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1681274903; bh=VDa3yGOxZOkIKUoi4MUQFdW7uP1qiz4EHSVTUPJnmSU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hJrKDRJhhVmd8lGFBBdGrqXrxa8SvIYD/OVHSHI5bMuc7jafZw/2DJPo5Cb5sKBEg rPGYeyVguZW9lpEdgGuaytzWShZ78htL1MtePgiMspqtGo7c+cgJjxYtQjBRAE6A8b 06bE1EIwlni+WZDyLEWjkqD8v+V/sAiTSCEG9rQI= Message-ID: Date: Tue, 11 Apr 2023 23:48:21 -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 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> From: "Madhavan T. Venkataraman" In-Reply-To: <20230412041752.i4raswvrnacnjjgy@treble> 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: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 > 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. > 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 A05ECC77B6E for ; Wed, 12 Apr 2023 04:49:38 +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=FSxwsHHPk/2FsPG7lF702DuacgqM7ezrGUCRBOk73cM=; b=wCXs725Pvq4hoO CTNM9iZe1llEasbbpX0vEkhAjg4sENmTIAYMTBquujq3fMVuQGtoUyyz7tsM+m5RZutTiSAgCEeFI +R5XR/eKO8bVztomFgz+nvALucVqqNTB5ZUenCh+PZFHZJkcLUMxX+I4rOjRrXj+mJERkUZJYmtKS ovMc1vEW3tkDOMxClBDxP2obQsDdShgvxoOEtK1vScwVW9FFSuCe+LQejQ2N+qejbwdmgNHxCtpdL 6EWBQ6ZtUZdT1ApCpRsi+RDyiEigu2celqxWO2Ew3Mf7Cuv2F+IafSp85CJwWeCzOAn9TwpKXXtKN Oxle+JU6XfBHeJaZZ4OQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmSPE-001mtT-0l; Wed, 12 Apr 2023 04:48:28 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pmSPB-001msl-2m for linux-arm-kernel@lists.infradead.org; Wed, 12 Apr 2023 04:48:27 +0000 Received: from [192.168.254.32] (unknown [47.189.246.67]) by linux.microsoft.com (Postfix) with ESMTPSA id 9F03221779AC; Tue, 11 Apr 2023 21:48:22 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9F03221779AC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1681274903; bh=VDa3yGOxZOkIKUoi4MUQFdW7uP1qiz4EHSVTUPJnmSU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hJrKDRJhhVmd8lGFBBdGrqXrxa8SvIYD/OVHSHI5bMuc7jafZw/2DJPo5Cb5sKBEg rPGYeyVguZW9lpEdgGuaytzWShZ78htL1MtePgiMspqtGo7c+cgJjxYtQjBRAE6A8b 06bE1EIwlni+WZDyLEWjkqD8v+V/sAiTSCEG9rQI= Message-ID: Date: Tue, 11 Apr 2023 23:48:21 -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 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> From: "Madhavan T. Venkataraman" In-Reply-To: <20230412041752.i4raswvrnacnjjgy@treble> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230411_214825_968626_46CCB988 X-CRM114-Status: GOOD ( 20.25 ) 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: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 > 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