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: <a7e45ab5-c583-9077-5747-9a3d3b7274e7@linux.microsoft.com>
Date:   Wed, 12 Apr 2023 09:50:23 -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
To:     Josh Poimboeuf <jpoimboe@kernel.org>
Cc:     Mark Rutland <mark.rutland@arm.com>, 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>
 <c7e1df79-1506-4502-035b-24ddf6848311@linux.microsoft.com>
 <20230412050106.7v4s3lalg43i6ciw@treble>
Content-Language: en-US
From:   "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
In-Reply-To: <20230412050106.7v4s3lalg43i6ciw@treble>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 4/12/23 00:01, Josh Poimboeuf wrote:
> 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).
> 

Yes. It is a much simplified version of DWARF. So, I am hoping that the compiler folks
can provide the feature with a reliability guarantee. DWARF is too complex.

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