[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <35520c4e-b7e4-6d98-c094-f7fea73d755b@oracle.com>
Date: Sun, 16 Apr 2023 01:21:43 -0700
From: Indu Bhagat <indu.bhagat@...cle.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>,
"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,
linux-toolchains@...r.kernel.org
Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame
pointer validation
On 4/13/23 9:30 AM, Josh Poimboeuf wrote:
> On Thu, Apr 13, 2023 at 09:59:31AM -0500, Madhavan T. Venkataraman wrote:
>> On 4/12/23 10:52, Josh Poimboeuf wrote:
>>> On Wed, Apr 12, 2023 at 09:50:23AM -0500, Madhavan T. Venkataraman wrote:
>>>>>> 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.
>>>
>>> I don't see what the complexity (or lack thereof) of the unwinding data
>>> format has to do with it. The unreliability comes from the underlying
>>> data source, not the formatting of the data.
>>>
>>
>> What I meant is - if SFrame is implemented by simply extracting unwind info from
>> DWARF data and placing it in a separate section (as it is probably implemented now),
>> then what you say is totally true. But if the compiler folks agree to make SFrame reliable,
>> then either they have to make DWARF reliable. Or, they have to implement SFrame as a
>> separate feature and make it reliable. The former is tough to do as DWARF has a lot of complexity.
>> The latter is a lot easier to do.
SFrame stack trace data is generated by the GNU assembler, by using the
.cfi_* asm directives embedded by the compiler. So, it is true that the
source of EH_Frame info and SFrame stack trace data is the same.
That said, yes, if you see bugs/inconsistencies in SFrame/EH_Frame info,
please file the issue(s).
>
> [ adding linux-toolchains ]
>
> I don't think ensuring reliability is an easy task, regardless of the
> complexity of the unwinding format.
>
> Whether it's SFrame or DWARF/eh_frame, the question would be how to
> ensure it's always reliable for a compiler "power user" like the kernel
> which has many edge cases (including lots of inline asm which the
> compiler has no visibility to) and which uses unwinding for more than
> just debugging.
>
> It would need some kind of black-box testing on a complex code base.
> (hint: kind of like what objtool already does today)
>
Powered by blists - more mailing lists