From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: Josh Poimboeuf <jpoimboe@kernel.org>, Mark Rutland <mark.rutland@arm.com> 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 Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Date: Tue, 11 Apr 2023 23:48:21 -0500 [thread overview] Message-ID: <c7e1df79-1506-4502-035b-24ddf6848311@linux.microsoft.com> (raw) In-Reply-To: <20230412041752.i4raswvrnacnjjgy@treble> 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. >
WARNING: multiple messages have this Message-ID (diff)
From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com> To: Josh Poimboeuf <jpoimboe@kernel.org>, Mark Rutland <mark.rutland@arm.com> 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 Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Date: Tue, 11 Apr 2023 23:48:21 -0500 [thread overview] Message-ID: <c7e1df79-1506-4502-035b-24ddf6848311@linux.microsoft.com> (raw) In-Reply-To: <20230412041752.i4raswvrnacnjjgy@treble> 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
next prev parent reply other threads:[~2023-04-12 4:48 UTC|newest] Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <0337266cf19f4c98388e3f6d09f590d9de258dc7> 2023-02-02 7:40 ` [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 01/22] objtool: Reorganize CFI code madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 02/22] objtool: Reorganize instruction-related code madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 03/22] objtool: Move decode_instructions() to a separate file madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 04/22] objtool: Reorganize Unwind hint code madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 05/22] objtool: Reorganize ORC types madvenka 2023-02-02 7:40 ` madvenka 2023-02-18 9:30 ` Suraj Jitindar Singh 2023-02-18 9:30 ` Suraj Jitindar Singh 2023-03-06 16:45 ` Madhavan T. Venkataraman 2023-03-06 16:45 ` Madhavan T. Venkataraman 2023-02-02 7:40 ` [RFC PATCH v3 06/22] objtool: Reorganize ORC code madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 07/22] objtool: Reorganize ORC kernel code madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 08/22] objtool: Introduce STATIC_CHECK madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 09/22] objtool: arm64: Add basic definitions and compile madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 10/22] objtool: arm64: Implement decoder for Dynamic FP validation madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 11/22] objtool: arm64: Invoke the decoder madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 12/22] objtool: arm64: Compute destinations for call and jump instructions madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 13/22] objtool: arm64: Walk instructions and compute CFI for each instruction madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 14/22] objtool: arm64: Generate ORC data from CFI for object files madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 15/22] objtool: arm64: Add unwind hint support madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 16/22] arm64: Add unwind hints to exception handlers madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 17/22] arm64: Add kernel and module support for ORC madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 18/22] arm64: Build the kernel with ORC information madvenka 2023-02-02 7:40 ` madvenka 2023-02-10 7:52 ` Tomohiro Misono (Fujitsu) 2023-02-10 7:52 ` Tomohiro Misono (Fujitsu) 2023-02-11 4:34 ` Madhavan T. Venkataraman 2023-02-11 4:34 ` Madhavan T. Venkataraman 2023-02-02 7:40 ` [RFC PATCH v3 19/22] arm64: unwinder: Add a reliability check in the unwinder based on ORC madvenka 2023-02-02 7:40 ` madvenka 2023-02-23 4:07 ` Suraj Jitindar Singh 2023-02-23 4:07 ` Suraj Jitindar Singh 2023-03-06 16:52 ` Madhavan T. Venkataraman 2023-03-06 16:52 ` Madhavan T. Venkataraman 2023-02-02 7:40 ` [RFC PATCH v3 20/22] arm64: Define HAVE_DYNAMIC_FTRACE_WITH_ARGS madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 21/22] arm64: Define TIF_PATCH_PENDING for livepatch madvenka 2023-02-02 7:40 ` madvenka 2023-02-02 7:40 ` [RFC PATCH v3 22/22] arm64: Enable livepatch for ARM64 madvenka 2023-02-02 7:40 ` madvenka 2023-03-01 3:12 ` [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Tomohiro Misono (Fujitsu) 2023-03-01 3:12 ` Tomohiro Misono (Fujitsu) 2023-03-02 16:23 ` Petr Mladek 2023-03-02 16:23 ` Petr Mladek 2023-03-03 9:40 ` Tomohiro Misono (Fujitsu) 2023-03-03 9:40 ` Tomohiro Misono (Fujitsu) 2023-03-06 16:58 ` Madhavan T. Venkataraman 2023-03-06 16:58 ` Madhavan T. Venkataraman 2023-03-06 16:57 ` Madhavan T. Venkataraman 2023-03-06 16:57 ` Madhavan T. Venkataraman 2023-03-23 17:17 ` Mark Rutland 2023-03-23 17:17 ` Mark Rutland 2023-04-08 3:40 ` Madhavan T. Venkataraman 2023-04-08 3:40 ` Madhavan T. Venkataraman 2023-04-11 13:25 ` Mark Rutland 2023-04-11 13:25 ` Mark Rutland 2023-04-12 4:17 ` Josh Poimboeuf 2023-04-12 4:17 ` Josh Poimboeuf 2023-04-12 4:48 ` Madhavan T. Venkataraman [this message] 2023-04-12 4:48 ` Madhavan T. Venkataraman 2023-04-12 4:50 ` Madhavan T. Venkataraman 2023-04-12 4:50 ` Madhavan T. Venkataraman 2023-04-12 5:01 ` Josh Poimboeuf 2023-04-12 5:01 ` Josh Poimboeuf 2023-04-12 14:50 ` Madhavan T. Venkataraman 2023-04-12 14:50 ` Madhavan T. Venkataraman 2023-04-12 15:52 ` Josh Poimboeuf 2023-04-12 15:52 ` Josh Poimboeuf 2023-04-13 14:59 ` Madhavan T. Venkataraman 2023-04-13 14:59 ` Madhavan T. Venkataraman 2023-04-13 16:30 ` Josh Poimboeuf 2023-04-13 16:30 ` Josh Poimboeuf 2023-04-15 4:27 ` Madhavan T. Venkataraman 2023-04-15 4:27 ` Madhavan T. Venkataraman 2023-04-15 5:05 ` Josh Poimboeuf 2023-04-15 5:05 ` Josh Poimboeuf 2023-04-15 16:15 ` Madhavan T. Venkataraman 2023-04-15 16:15 ` Madhavan T. Venkataraman 2023-04-16 8:21 ` Indu Bhagat 2023-04-16 8:21 ` Indu Bhagat 2023-04-13 17:04 ` Nick Desaulniers 2023-04-13 17:04 ` Nick Desaulniers 2023-04-13 18:15 ` Jose E. Marchesi 2023-04-13 18:15 ` Jose E. Marchesi 2023-04-15 4:14 ` Madhavan T. Venkataraman 2023-04-15 4:14 ` Madhavan T. Venkataraman 2023-12-14 20:49 ` ARM64 Livepatch based on SFrame Madhavan T. Venkataraman 2023-12-14 20:49 ` Madhavan T. Venkataraman 2023-12-15 13:04 ` Mark Rutland 2023-12-15 13:04 ` Mark Rutland 2023-12-15 15:15 ` Madhavan T. Venkataraman 2023-12-15 15:15 ` Madhavan T. Venkataraman 2023-04-03 22:26 [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Dylan Hatch 2023-04-08 3:41 ` Madhavan T. Venkataraman 2023-04-08 3:41 ` Madhavan T. Venkataraman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c7e1df79-1506-4502-035b-24ddf6848311@linux.microsoft.com \ --to=madvenka@linux.microsoft.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=chenzhongjin@huawei.com \ --cc=jamorris@linux.microsoft.com \ --cc=jpoimboe@kernel.org \ --cc=jpoimboe@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=live-patching@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=nobuta.keiya@fujitsu.com \ --cc=peterz@infradead.org \ --cc=sjitindarsingh@gmail.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.