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 66B69C7619A for ; Sat, 15 Apr 2023 05:06:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229496AbjDOFGE (ORCPT ); Sat, 15 Apr 2023 01:06:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbjDOFGD (ORCPT ); Sat, 15 Apr 2023 01:06:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 93FB94C2B; Fri, 14 Apr 2023 22:06:00 -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 D3A2361BC5; Sat, 15 Apr 2023 05:05:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D1B1C433D2; Sat, 15 Apr 2023 05:05:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681535159; bh=XOIJuxXHCj+rkGybuZPerdCBU1hgQaWT6pZnlBVE1nE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i3U9k+O3VHIIZEC2+EhtmpMMVSjZZzq3kTeqKL2XzTLENPtmfxZzhWjNbHiyghVKM lCKJkJO/YGCgTbuUessQ/5nzd5zXACdYVEKGlHGrvkgBpiS0Gyn73esckKwSnY3kUQ xcxVn1Dx6QxoUJHheqJemZibhbSh+S9XKe4U75b9jkFa51xuaZvzxPIIs2Xw5Di9mi v0gl+uMQzh1IJynRN2MCMjhftuIBKrszkBD/gG+Bd3PxjlXAiHdEiO5bfu+fdV/f+6 NAGaBPOLGAp56Nn1udzmfs7qnYk8cAdz8W4HIJTYCRzLle4VY/E9HBt2vI6IGOkff2 bSZlbNywZ4uEw== Date: Fri, 14 Apr 2023 22:05:56 -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, linux-toolchains@vger.kernel.org Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Message-ID: <20230415050556.isimfnqnsgwmerkf@treble> References: <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com> <20230412041752.i4raswvrnacnjjgy@treble> <20230412050106.7v4s3lalg43i6ciw@treble> <20230412155221.2l2mqsyothseymeq@treble> <20230413163035.ttar5uexrpldz3yl@treble> <4e5029f4-be42-ef23-1eab-a6cfff49527c@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4e5029f4-be42-ef23-1eab-a6cfff49527c@linux.microsoft.com> Precedence: bulk List-ID: X-Mailing-List: live-patching@vger.kernel.org On Fri, Apr 14, 2023 at 11:27:44PM -0500, Madhavan T. Venkataraman wrote: > >> 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. > > > > [ adding linux-toolchains ] > > > > I don't think ensuring reliability is an easy task, regardless of the > > complexity of the unwinding format. > > > > Whether it's SFrame or DWARF/eh_frame, the question would be how to > > ensure it's always reliable for a compiler "power user" like the kernel > > which has many edge cases (including lots of inline asm which the > > compiler has no visibility to) and which uses unwinding for more than > > just debugging. > > > > It would need some kind of black-box testing on a complex code base. > > (hint: kind of like what objtool already does today) > > > > I could use the ORC data I generate by using the decoder against the SFrame data. > A function is reliable only if both data sources agree for the whole function. This is somewhat similar to what I'm saying in another thread: https://lore.kernel.org/live-patching/20230415043949.7y4tvshe26zday3e@treble/ If objtool and DWARF/SFrame agree, all is well. > Also, in my approach, the actual frame pointer is dynamically checked against the > frame pointer computed from the unwind data. Any mismatch indicates an unreliable stack trace. > > IMHO, this is sufficient to provide livepatch. Do you agree? The dynamic reliable stacktrace checks for CONFIG_FRAME_POINTER on x86 are much simpler, as they don't require ORC or any other metadata. They just need to detect preemption and page faults on the stack, and to identify the end of the stack. Those simple dynamic checks, combined with objtool's build-time frame pointer validation, worked very well until we switched to ORC. So I'm not sure I see the benefit of the additional complexity involved in cross-checking frame pointers with ORC at runtime. But I'm just a bystander. What really matters is what the arm64 folks think ;-) -- 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 C10AEC77B71 for ; Sat, 15 Apr 2023 05:06:53 +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=1de1OtN57AxeIsZdNXGujcmL3w6R7CUDy4+CBy/tAIE=; b=cEXkajDgMJwhSP sLbF8tnd4pGy2AIATuktypzyawwzTLrKwuJW54ppENxcDL9q+V2/dZHXe2CMLhe71lewqkPhjGr6C ClpKAz8tITkYecKELNOZ2LrgIZmzAk1nqoM9aEQXSrecQJ+IO+d50SdVI6fXT+pTwiWtx+M4dwFqM XG9O1eYRVZJKSDQxP9Wfy9iccYVsEGbSbN9Rdz390GlIQ4xXv1wd4mt5TeBnoGX/BopxgpmeSlHdO H8oSt45bKsdSxRhiGrIkIanppEbJV1O1N5ZqqsunS+A9KawtuUM2cZy5pHAdMvowQZCImJoY6jA0M SJwwmhvSRODcAfnh8hHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pnY6t-00BKyq-2m; Sat, 15 Apr 2023 05:06:03 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pnY6q-00BKxv-1h for linux-arm-kernel@lists.infradead.org; Sat, 15 Apr 2023 05:06:02 +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 C817F60E8A; Sat, 15 Apr 2023 05:05:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D1B1C433D2; Sat, 15 Apr 2023 05:05:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681535159; bh=XOIJuxXHCj+rkGybuZPerdCBU1hgQaWT6pZnlBVE1nE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i3U9k+O3VHIIZEC2+EhtmpMMVSjZZzq3kTeqKL2XzTLENPtmfxZzhWjNbHiyghVKM lCKJkJO/YGCgTbuUessQ/5nzd5zXACdYVEKGlHGrvkgBpiS0Gyn73esckKwSnY3kUQ xcxVn1Dx6QxoUJHheqJemZibhbSh+S9XKe4U75b9jkFa51xuaZvzxPIIs2Xw5Di9mi v0gl+uMQzh1IJynRN2MCMjhftuIBKrszkBD/gG+Bd3PxjlXAiHdEiO5bfu+fdV/f+6 NAGaBPOLGAp56Nn1udzmfs7qnYk8cAdz8W4HIJTYCRzLle4VY/E9HBt2vI6IGOkff2 bSZlbNywZ4uEw== Date: Fri, 14 Apr 2023 22:05:56 -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, linux-toolchains@vger.kernel.org Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Message-ID: <20230415050556.isimfnqnsgwmerkf@treble> References: <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com> <20230412041752.i4raswvrnacnjjgy@treble> <20230412050106.7v4s3lalg43i6ciw@treble> <20230412155221.2l2mqsyothseymeq@treble> <20230413163035.ttar5uexrpldz3yl@treble> <4e5029f4-be42-ef23-1eab-a6cfff49527c@linux.microsoft.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4e5029f4-be42-ef23-1eab-a6cfff49527c@linux.microsoft.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230414_220600_646112_08835D3D X-CRM114-Status: GOOD ( 25.08 ) 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 Fri, Apr 14, 2023 at 11:27:44PM -0500, Madhavan T. Venkataraman wrote: > >> 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. > > > > [ adding linux-toolchains ] > > > > I don't think ensuring reliability is an easy task, regardless of the > > complexity of the unwinding format. > > > > Whether it's SFrame or DWARF/eh_frame, the question would be how to > > ensure it's always reliable for a compiler "power user" like the kernel > > which has many edge cases (including lots of inline asm which the > > compiler has no visibility to) and which uses unwinding for more than > > just debugging. > > > > It would need some kind of black-box testing on a complex code base. > > (hint: kind of like what objtool already does today) > > > > I could use the ORC data I generate by using the decoder against the SFrame data. > A function is reliable only if both data sources agree for the whole function. This is somewhat similar to what I'm saying in another thread: https://lore.kernel.org/live-patching/20230415043949.7y4tvshe26zday3e@treble/ If objtool and DWARF/SFrame agree, all is well. > Also, in my approach, the actual frame pointer is dynamically checked against the > frame pointer computed from the unwind data. Any mismatch indicates an unreliable stack trace. > > IMHO, this is sufficient to provide livepatch. Do you agree? The dynamic reliable stacktrace checks for CONFIG_FRAME_POINTER on x86 are much simpler, as they don't require ORC or any other metadata. They just need to detect preemption and page faults on the stack, and to identify the end of the stack. Those simple dynamic checks, combined with objtool's build-time frame pointer validation, worked very well until we switched to ORC. So I'm not sure I see the benefit of the additional complexity involved in cross-checking frame pointers with ORC at runtime. But I'm just a bystander. What really matters is what the arm64 folks think ;-) -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel