On 4/12/23 00:01, Josh Poimboeuf wrote: > 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). > Yes. It is a much simplified version of DWARF. So, I am hoping that the compiler folks can provide the feature with a reliability guarantee. DWARF is too complex. 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. >
