On 4/11/23 23:48, 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? > > Madhavan > Just to be clear. This is not to replace Objtool as it has other uses as well, not just reliable stack trace. I am trying to solve the reliable stack trace issue alone with SFrame. 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. >>
