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;
Date:   Wed, 12 Apr 2023 08:52:21 -0700
From:   Josh Poimboeuf <jpoimboe@kernel.org>
To:     "Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>
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
Subject: Re: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame
 pointer validation
Message-ID: <20230412155221.2l2mqsyothseymeq@treble>
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>
 <a7e45ab5-c583-9077-5747-9a3d3b7274e7@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <a7e45ab5-c583-9077-5747-9a3d3b7274e7@linux.microsoft.com>
Precedence: bulk

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.

-- 
Josh