Message-ID: <20230412050106.7v4s3lalg43i6ciw@treble>
Date:   Tue, 11 Apr 2023 22:01:06 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>
Cc:     Mark Rutland <mark.rutland@....com>, jpoimboe@...hat.com,
        peterz@...radead.org, chenzhongjin@...wei.com, broonie@...nel.org,
        nobuta.keiya@...itsu.com, sjitindarsingh@...il.com,
        catalin.marinas@....com, will@...nel.org,
        jamorris@...ux.microsoft.com, linux-arm-kernel@...ts.infradead.org,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame
 pointer validation

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

Powered by blists - more mailing lists