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). > > 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. -- Josh
