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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. 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



--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux