Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c7e1df79-1506-4502-035b-24ddf6848311@linux.microsoft.com>
Date:   Tue, 11 Apr 2023 23:48:21 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame
 pointer validation
Content-Language: en-US
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
References: <0337266cf19f4c98388e3f6d09f590d9de258dc7>
 <20230202074036.507249-1-madvenka@linux.microsoft.com>
 <ZByJmnc/XDcqQwoZ@FVFF77S0Q05N.cambridge.arm.com>
 <054ce0d6-70f0-b834-d4e5-1049c8df7492@linux.microsoft.com>
 <ZDVft9kysWMfTiZW@FVFF77S0Q05N> <20230412041752.i4raswvrnacnjjgy@treble>
From:   "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
In-Reply-To: <20230412041752.i4raswvrnacnjjgy@treble>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


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

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