[Crash-utility] [PATCH v2] Determine the ARM64 kernel's Pointer Authentication mask value by reading the new KERNELPACMASK vmcoreinfo entry.

[Amit Kachhap]

Hi Dave,

On 4/23/20 1:20 PM, Amit Kachhap wrote:
> Hi Dave,
> 
> On 4/22/20 7:29 PM, Dave Anderson wrote:
>> Hi Amit,
>>
>> Two more questions below...
>>
>> ----- Original Message -----
>>
>>>> But here's where I'm confused: when an in-kernel exception frame 
>>>> occurs, and the
>>>> processor lays down the full register set on the stack, are both the 
>>>> PC and LR (regs[30])
>>>> text values written on the stack as obfuscated values?
>>>>
>>>
>>> In arm64 case arch/arm64/include/asm/kexec.h + crash_setup_regs()
>>> function sets up the kernel exception frame. As can be seen PC does not
>>> have obfuscated (PAC) values but LR can be obfuscated.
>>
>> Ok, so that's when it's setting up the registers for a kexec/kdump 
>> operation.
>>
>> But what about exceptions that occur during the normal course of 
>> events, such as
>> when an interrupt or page fault occurs?
> 
> pc will never have obfuscated value as obfuscated value can reside 
> either in lr or stack.
> The epilogue of function where return to lr register happens is usually 
> like,
> 
> ldp     x29, x30, [sp], #16 // optional if x29, x30 is not corrupted
> autiasp
> ret
> 
> Here autiasp clears the obfuscated value then pc is set to lr with ret 
> address.
> If autiasp fails then the lr top byte is set to some bit pattern and pc=lr
> Note that KERNELPACMASK or obfuscated value starts below from top byte 
> and leaves the top byte as it is.

A small correction, top bytes are included in KERNELPACMASK but that is 
configurable. Anyway so when autiasp(authentication) instruction fails 
then all obfuscated value is cleared and a error bit pattern is added 
only in top byte.
As mentioned earlier armv8.6 enhanced PAC will not add bit pattern to 
denote failure but will cause illegal instruction fault with an 
exception class and hence pc will not have extra details. This is work 
in progress so the current crash utility changes should work fine.


Even pointer authentication backtrace
> shows the PC with top byte as the corrupted bit pattern. This error bit
> pattern was not properly defined in armv8.3 architecture manual so left 
> like this. In this case symbol search may fail here.
> 
> I am also working on armv8.6(patches floating in mailing list) where if 
> autiasp fails then proper pointer authentication exception is generated 
> so pc top byte will be without any error bit pattern and all the changes 
> done here should work fine.
> 
>>
>>>> ...
>>>>
>>>> When it gathers the starting hooks for non-active tasks, it does this:
>>>>
>>>>     static int
>>>>     arm64_get_stackframe(struct bt_info *bt, struct arm64_stackframe 
>>>> *frame)crash_setup_regs
>>>>     {
>>>>             if (!fill_task_struct(bt->task))
>>>>                     return FALSE;
>>>>             frame->sp = ULONG(tt->task_struct + 
>>>> OFFSET(task_struct_thread_context_sp));
>>>>             frame->pc = ULONG(tt->task_struct + 
>>>> OFFSET(task_struct_thread_context_pc));
>>>>             frame->fp = ULONG(tt->task_struct + 
>>>> OFFSET(task_struct_thread_context_fp));
>>>>             return TRUE;
>>>>     }
>>>> When a task is put to sleep, is the PC text address in the task's 
>>>> thread_struct.cpu_context
>>>> obfuscated?
>>
>> And again, what happens in this case?
> 
> Oh I forgot to add my reply for this.
> The above reasoning may hold here too.
> 
> Cheers,
> Amit
> 
>>
>> Thanks,
>>    Dave
>>