Message-ID: <8b7b779b-6552-c637-9a84-4dbc95fd0c07@linux.microsoft.com>
Date:   Tue, 11 Apr 2023 23:50:51 -0500
From:   "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>
To:     Josh Poimboeuf <jpoimboe@...nel.org>,
        Mark Rutland <mark.rutland@....com>
Cc:     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 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.
>>

Powered by blists - more mailing lists