Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation

From: "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>
Cc: jpoimboe@redhat.com, peterz@infradead.org,
	chenzhongjin@huawei.com, broonie@kernel.org,
	nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com,
	catalin.marinas@arm.com, will@kernel.org,
	jamorris@linux.microsoft.com,
	linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation
Date: Tue, 11 Apr 2023 23:50:51 -0500	[thread overview]
Message-ID: <8b7b779b-6552-c637-9a84-4dbc95fd0c07@linux.microsoft.com> (raw)
In-Reply-To: <c7e1df79-1506-4502-035b-24ddf6848311@linux.microsoft.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel