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

[Indu Bhagat]

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)