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

[James Clark]

On 03/03/2026 3:26 pm, Jakub Brnak wrote:
> 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
> 

Sure, I can put it back on the todo list.