Re: [PATCH v2 1/1] perf arm64: Send pointer auth masks to ring buffer

[Jakub Brnak]

On Tue, Mar 03, 2026 at 10:38:23AM +0000, James Clark wrote:
> 
> 
> On 02/03/2026 4:33 pm, Jakub Brnak wrote:
> > On Mon, Oct 31, 2022 at 01:48:56PM +0000, James Clark wrote:
> > > 
> > > 
> > > On 27/10/2022 18:20, Peter Zijlstra wrote:
> > > > On Tue, Oct 25, 2022 at 04:28:12PM +0100, James Clark wrote:
> > > > 
> > > > > > Why do we want the same mask repeated over and over with each sample;
> > > > > > should this not be part of the address space (side-band) data?
> > > > > 
> > > > > You are probably right that it could be done that way. The reason that
> > > > > we did it this way was to be consistent with ptrace feature [1] where it
> > > > > is delivered to userspace on a per-process basis. And there is also a
> > > > > prctl for the enabled key types [2] which can be changed dynamically.
> > > > > Particularly for the last reason is why it was done per sample.
> > > > > 
> > > > > Having said that, the enabled keys field is not used by perf, only the
> > > > > mask is used, so I can drop the per sample data until enabled keys is
> > > > > needed, which may be never.
> > > > > 
> > > > > I'm going to assume that perf shouldn't use ptrace because of
> > > > > permissions and conflicts with debuggers, so I could put the mask
> > > > > somewhere like PERF_RECORD_FORK instead of per sample.
> > > > 
> > > > Yeah, or create an new RECORD type which you can also send around at
> > > > prctl() time.
> > > > 
> > > > The only thing that's needed on top of that is exposing the mask
> > > > somewhere in /proc for existing tasks; which is what perf also uses to
> > > > syntesize RECORD_MMAP events on startup etc..
> > > > 
> > > 
> > > Hmm ok, in that case I can just add the /proc interface for now because
> > > the mask won't change and we can add the new record type at the point
> > > it's needed in the future.
> > > 
> > > Thanks for the feedback.
> > 
> > Hi all,
> > 
> > Does anyone know how this issue was eventually resolved?
> > Specifically, is the mask for the pointer authentication bits
> > currently exposed and stored somewhere in perf.data so it can be
> > used when running perf report?
> > 
> > Thanks,
> > Jakub
> > 
> > 
> 
> Hi Jakub,
> 
> No we never finished this, you're actually the first person to mention it.
> Can you give a bit more detail about your use case? Maybe we can dig out the
> old branches and work on it again.
> 
> For a summary of the current status, frame pointer unwinds in the kernel are
> working with pointer auth because the kernel strips them.
> 
> We patched libunwind for support on commit f67ef2867bc5 ("Unwind with
> pointer authentication on arm64"). And libdw on commit 0af6c7289c22
> (libdwfl, aarch64: Demangle return addresses using a PAC mask). These two
> were to support dwarf unwinding, but the kernel changes to expose the mask
> and Perf changes to pass it to the unwinders were never finished.
> 
> Thanks
> James
>

Hi James,

Thanks for the answer. I was investigating a failure in one of the perf tests on 
AArch64 RHEL-10 that verifies stack unwinding using DWARF, and it was consistently 
failing. I dug a bit deeper and discovered that DWARF unwinding in perf report does 
not work correctly at all, and addresses polluted by PAC bits are likely the cause. 
I stepped through the program and observed that in libdw the code path responsible for 
masking these bits is executed, but the mask is always set to 0 and therefore has no effect. 
During the unwinding process, there is a structure that is supposed to store the 
mask and use it later. However, since perf constructs the unwinding context offline from samples 
and currently does not store the mask anywhere in perf.data, there is likely a no way to propagate 
it into that structure. It would be nice if we could push this forward. 

Thanks, 
Jakub