Re: [Crash-utility] [External Mail][营销邮件] Re: ramdump support for va_bits_actual
Vinayak? - Original Message - > Hi,Vinayakm > > I don't think it's necessary to judge physvirt_offset if empty in > arm64_VTOP,because physvirt_offset always be initialized by > arm64_calc_physvirt_offset,so machdep->machspec->physvirt_offset always > true.even if older kernel are compatible. > > so,how about the following change? > > @@ -1148,8 +1155,7 @@ arm64_VTOP(ulong addr) > } > > if (addr >= machdep->machspec->page_offset) > - return machdep->machspec->phys_offset > - + (addr - machdep->machspec->page_offset); > + return (addr + machdep->machspec->physvirt_offset); > > > From: crash-utility-boun...@redhat.com on > behalf of vinayak menon > Sent: Tuesday, April 21, 2020 18:01 > To: Discussion list for crash utility usage,maintenance and development > Subject: [External Mail][营销邮件] Re: [Crash-utility] ramdump support for > va_bits_actual > > Hi Dave, zhaoqianli > > > Yeah, that looks reasonable. But what about the parallel discussion re: > > vmemmap_start? > > > > https://www.redhat.com/archives/crash-utility/2020-April/msg00064.html > > I have picked up the vmemmap_start as 4th patch. The physvirt_offset > based VTOP is already > part of patchset 1. I hope I have not missed anything from those > recommended by Zhaogianli. > > > > > Can you send in an updated patch set with all fixes applied? > > PFA. > > Thanks, > Vinayak > #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments contain confidential information from > XIAOMI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it!**/# > > -- > Crash-utility mailing list > Crash-utility@redhat.com > https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] new printk ringbuffer interface
> -Original Message- > > -Original Message- > > - Original Message - > > > ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk.. > > > > > > > -Original Message- > > > > > > > > - Original Message - > > > > > Hello Dave, > > > > > > > > > > You may or may not be aware that we are working on replacing [0] the > > > > > Linux printk ringbuffer. Rather than a single buffer containing a > > > > > single > > > > > struct type, the new ringbuffer makes use of several different > > > > > structs. > > > > > > > > Yes, I am most definitely aware... > > > > > > > > > > > > > > I am writing to ask your advice about how this should be exported for > > > > > the crash utility. Should all struct sizes and field offsets be > > > > > exported? It would look something like this: > > > > > > > > > > VMCOREINFO_SYMBOL(prb); > > > > > > > > > > VMCOREINFO_STRUCT_SIZE(printk_ringbuffer); > > > > > VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring); > > > > > VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring); > > > > > VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring); > > > > > VMCOREINFO_OFFSET(printk_ringbuffer, fail); > > > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_desc_ring); > > > > > VMCOREINFO_OFFSET(prb_desc_ring, count_bits); > > > > > VMCOREINFO_OFFSET(prb_desc_ring, descs); > > > > > VMCOREINFO_OFFSET(prb_desc_ring, head_id); > > > > > VMCOREINFO_OFFSET(prb_desc_ring, tail_id); > > > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_desc); > > > > > VMCOREINFO_OFFSET(prb_desc, info); > > > > > VMCOREINFO_OFFSET(prb_desc, state_var); > > > > > VMCOREINFO_OFFSET(prb_desc, text_blk_lpos); > > > > > VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos); > > > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos); > > > > > VMCOREINFO_OFFSET(prb_data_blk_lpos, begin); > > > > > VMCOREINFO_OFFSET(prb_data_blk_lpos, next); > > > > > > > > > > VMCOREINFO_STRUCT_SIZE(printk_info); > > > > > VMCOREINFO_OFFSET(printk_info, seq); > > > > > VMCOREINFO_OFFSET(printk_info, ts_nsec); > > > > > VMCOREINFO_OFFSET(printk_info, text_len); > > > > > VMCOREINFO_OFFSET(printk_info, dict_len); > > > > > VMCOREINFO_OFFSET(printk_info, caller_id); > > > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_data_ring); > > > > > VMCOREINFO_OFFSET(prb_data_ring, size_bits); > > > > > VMCOREINFO_OFFSET(prb_data_ring, data); > > > > > VMCOREINFO_OFFSET(prb_data_ring, head_id); > > > > > VMCOREINFO_OFFSET(prb_data_ring, tail_id); > > > > > > > > > > Or would it be enough to just recognize the new "prb" symbol and have > > > > > all the structures defined in the crash utility? If the latter is > > > > > preferred, should some sort of version number be exported? Or is the > > > > > kernel version number enough? > > > > > > first I don't think we can depend on the kernel version because > > > distribution > > > kernels backport upstream patches. So we will need a version number of > > > the > > > ringbuffer if we choose that way. > > > > With respect to the kernel version, you are absolutely correct, as we've > > been > > burnt by that before with backports to distribution and the upstream > > longterm > > kernels. But I think John was talking about exporting a > > printk-structure-set > > version number, so I think we're on the same page. > > > > Also, if we go the version-number route, there would still not be a > > requirement > > for the crash utility to duplicate the kernel data structures in its > > sources. > > As John's proof-of-concept patch showed, it can still use the traditional > > manner of getting structure sizes and member offsets. With the version > > number > > exported, there may have to be a few small adjustments in the > > MEMBER_OFFSET_INIT() > > calls, but it would be fairly straight-forward to maintain. > > > > But of course makedumpfile would have to replicate the kernel data > > structures. > > Ah, indeed. I vaguely thought makedumpfile also might be able to do like > crash > by setting sizes and offsets for each version.. But it will be hard to set > them > manually for every architectures. I'll think about it more. makedumpfile has some architecture or kernel version specific values in it and switches them by conditions, but the reason why we can do this is that they are mostly constants that rarely change and can be got from the kernel source easily. With respect to structure sizes and memger offsets, I don't think of a way to do this easily. And then if we define all the structures in makedumpfile with the version number, how can we implement them and switch for each version? The new ringbuffer is structured very much, I cannot imagine that it can be handled efficiently. Any ideas? If there is no efficient way, we will need all
Re: [Crash-utility] new printk ringbuffer interface
> -Original Message- > - Original Message - > > ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk.. > > > > > -Original Message- > > > > > > - Original Message - > > > > Hello Dave, > > > > > > > > You may or may not be aware that we are working on replacing [0] the > > > > Linux printk ringbuffer. Rather than a single buffer containing a single > > > > struct type, the new ringbuffer makes use of several different structs. > > > > > > Yes, I am most definitely aware... > > > > > > > > > > > I am writing to ask your advice about how this should be exported for > > > > the crash utility. Should all struct sizes and field offsets be > > > > exported? It would look something like this: > > > > > > > > VMCOREINFO_SYMBOL(prb); > > > > > > > > VMCOREINFO_STRUCT_SIZE(printk_ringbuffer); > > > > VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring); > > > > VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring); > > > > VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring); > > > > VMCOREINFO_OFFSET(printk_ringbuffer, fail); > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_desc_ring); > > > > VMCOREINFO_OFFSET(prb_desc_ring, count_bits); > > > > VMCOREINFO_OFFSET(prb_desc_ring, descs); > > > > VMCOREINFO_OFFSET(prb_desc_ring, head_id); > > > > VMCOREINFO_OFFSET(prb_desc_ring, tail_id); > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_desc); > > > > VMCOREINFO_OFFSET(prb_desc, info); > > > > VMCOREINFO_OFFSET(prb_desc, state_var); > > > > VMCOREINFO_OFFSET(prb_desc, text_blk_lpos); > > > > VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos); > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos); > > > > VMCOREINFO_OFFSET(prb_data_blk_lpos, begin); > > > > VMCOREINFO_OFFSET(prb_data_blk_lpos, next); > > > > > > > > VMCOREINFO_STRUCT_SIZE(printk_info); > > > > VMCOREINFO_OFFSET(printk_info, seq); > > > > VMCOREINFO_OFFSET(printk_info, ts_nsec); > > > > VMCOREINFO_OFFSET(printk_info, text_len); > > > > VMCOREINFO_OFFSET(printk_info, dict_len); > > > > VMCOREINFO_OFFSET(printk_info, caller_id); > > > > > > > > VMCOREINFO_STRUCT_SIZE(prb_data_ring); > > > > VMCOREINFO_OFFSET(prb_data_ring, size_bits); > > > > VMCOREINFO_OFFSET(prb_data_ring, data); > > > > VMCOREINFO_OFFSET(prb_data_ring, head_id); > > > > VMCOREINFO_OFFSET(prb_data_ring, tail_id); > > > > > > > > Or would it be enough to just recognize the new "prb" symbol and have > > > > all the structures defined in the crash utility? If the latter is > > > > preferred, should some sort of version number be exported? Or is the > > > > kernel version number enough? > > > > first I don't think we can depend on the kernel version because distribution > > kernels backport upstream patches. So we will need a version number of the > > ringbuffer if we choose that way. > > With respect to the kernel version, you are absolutely correct, as we've been > burnt by that before with backports to distribution and the upstream longterm > kernels. But I think John was talking about exporting a printk-structure-set > version number, so I think we're on the same page. > > Also, if we go the version-number route, there would still not be a > requirement > for the crash utility to duplicate the kernel data structures in its sources. > As John's proof-of-concept patch showed, it can still use the traditional > manner of getting structure sizes and member offsets. With the version number > exported, there may have to be a few small adjustments in the > MEMBER_OFFSET_INIT() > calls, but it would be fairly straight-forward to maintain. > > But of course makedumpfile would have to replicate the kernel data structures. Ah, indeed. I vaguely thought makedumpfile also might be able to do like crash by setting sizes and offsets for each version.. But it will be hard to set them manually for every architectures. I'll think about it more. Thanks, Kazu -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] new printk ringbuffer interface
- Original Message - > ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk.. > > > -Original Message- > > > > - Original Message - > > > Hello Dave, > > > > > > You may or may not be aware that we are working on replacing [0] the > > > Linux printk ringbuffer. Rather than a single buffer containing a single > > > struct type, the new ringbuffer makes use of several different structs. > > > > Yes, I am most definitely aware... > > > > > > > > I am writing to ask your advice about how this should be exported for > > > the crash utility. Should all struct sizes and field offsets be > > > exported? It would look something like this: > > > > > > VMCOREINFO_SYMBOL(prb); > > > > > > VMCOREINFO_STRUCT_SIZE(printk_ringbuffer); > > > VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring); > > > VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring); > > > VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring); > > > VMCOREINFO_OFFSET(printk_ringbuffer, fail); > > > > > > VMCOREINFO_STRUCT_SIZE(prb_desc_ring); > > > VMCOREINFO_OFFSET(prb_desc_ring, count_bits); > > > VMCOREINFO_OFFSET(prb_desc_ring, descs); > > > VMCOREINFO_OFFSET(prb_desc_ring, head_id); > > > VMCOREINFO_OFFSET(prb_desc_ring, tail_id); > > > > > > VMCOREINFO_STRUCT_SIZE(prb_desc); > > > VMCOREINFO_OFFSET(prb_desc, info); > > > VMCOREINFO_OFFSET(prb_desc, state_var); > > > VMCOREINFO_OFFSET(prb_desc, text_blk_lpos); > > > VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos); > > > > > > VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos); > > > VMCOREINFO_OFFSET(prb_data_blk_lpos, begin); > > > VMCOREINFO_OFFSET(prb_data_blk_lpos, next); > > > > > > VMCOREINFO_STRUCT_SIZE(printk_info); > > > VMCOREINFO_OFFSET(printk_info, seq); > > > VMCOREINFO_OFFSET(printk_info, ts_nsec); > > > VMCOREINFO_OFFSET(printk_info, text_len); > > > VMCOREINFO_OFFSET(printk_info, dict_len); > > > VMCOREINFO_OFFSET(printk_info, caller_id); > > > > > > VMCOREINFO_STRUCT_SIZE(prb_data_ring); > > > VMCOREINFO_OFFSET(prb_data_ring, size_bits); > > > VMCOREINFO_OFFSET(prb_data_ring, data); > > > VMCOREINFO_OFFSET(prb_data_ring, head_id); > > > VMCOREINFO_OFFSET(prb_data_ring, tail_id); > > > > > > Or would it be enough to just recognize the new "prb" symbol and have > > > all the structures defined in the crash utility? If the latter is > > > preferred, should some sort of version number be exported? Or is the > > > kernel version number enough? > > first I don't think we can depend on the kernel version because distribution > kernels backport upstream patches. So we will need a version number of the > ringbuffer if we choose that way. With respect to the kernel version, you are absolutely correct, as we've been burnt by that before with backports to distribution and the upstream longterm kernels. But I think John was talking about exporting a printk-structure-set version number, so I think we're on the same page. Also, if we go the version-number route, there would still not be a requirement for the crash utility to duplicate the kernel data structures in its sources. As John's proof-of-concept patch showed, it can still use the traditional manner of getting structure sizes and member offsets. With the version number exported, there may have to be a few small adjustments in the MEMBER_OFFSET_INIT() calls, but it would be fairly straight-forward to maintain. But of course makedumpfile would have to replicate the kernel data structures. Thanks, Dave -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] new printk ringbuffer interface
ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk.. > -Original Message- > > - Original Message - > > Hello Dave, > > > > You may or may not be aware that we are working on replacing [0] the > > Linux printk ringbuffer. Rather than a single buffer containing a single > > struct type, the new ringbuffer makes use of several different structs. > > Yes, I am most definitely aware... > > > > > I am writing to ask your advice about how this should be exported for > > the crash utility. Should all struct sizes and field offsets be > > exported? It would look something like this: > > > > VMCOREINFO_SYMBOL(prb); > > > > VMCOREINFO_STRUCT_SIZE(printk_ringbuffer); > > VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring); > > VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring); > > VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring); > > VMCOREINFO_OFFSET(printk_ringbuffer, fail); > > > > VMCOREINFO_STRUCT_SIZE(prb_desc_ring); > > VMCOREINFO_OFFSET(prb_desc_ring, count_bits); > > VMCOREINFO_OFFSET(prb_desc_ring, descs); > > VMCOREINFO_OFFSET(prb_desc_ring, head_id); > > VMCOREINFO_OFFSET(prb_desc_ring, tail_id); > > > > VMCOREINFO_STRUCT_SIZE(prb_desc); > > VMCOREINFO_OFFSET(prb_desc, info); > > VMCOREINFO_OFFSET(prb_desc, state_var); > > VMCOREINFO_OFFSET(prb_desc, text_blk_lpos); > > VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos); > > > > VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos); > > VMCOREINFO_OFFSET(prb_data_blk_lpos, begin); > > VMCOREINFO_OFFSET(prb_data_blk_lpos, next); > > > > VMCOREINFO_STRUCT_SIZE(printk_info); > > VMCOREINFO_OFFSET(printk_info, seq); > > VMCOREINFO_OFFSET(printk_info, ts_nsec); > > VMCOREINFO_OFFSET(printk_info, text_len); > > VMCOREINFO_OFFSET(printk_info, dict_len); > > VMCOREINFO_OFFSET(printk_info, caller_id); > > > > VMCOREINFO_STRUCT_SIZE(prb_data_ring); > > VMCOREINFO_OFFSET(prb_data_ring, size_bits); > > VMCOREINFO_OFFSET(prb_data_ring, data); > > VMCOREINFO_OFFSET(prb_data_ring, head_id); > > VMCOREINFO_OFFSET(prb_data_ring, tail_id); > > > > Or would it be enough to just recognize the new "prb" symbol and have > > all the structures defined in the crash utility? If the latter is > > preferred, should some sort of version number be exported? Or is the > > kernel version number enough? first I don't think we can depend on the kernel version because distribution kernels backport upstream patches. So we will need a version number of the ringbuffer if we choose that way. I think that "exporting all things" can sometimes reflect changes in kernel automatically and can reduce tool side effort more than "exporting a version number". But the former requires a lot of entries and it might be hard for us to track the changes. So having an explicit version might be better and I'm ok with the latter. But I hope no missing update of the version number.. Any thoughts from vmcore-dmesg side? Thanks, Kazu > > > > I appreciate your feedback. > > > > John Ogness > > With respect to the crash utility, there are two answers. > > When running crash session normally, i.e. running "crash vmlinux vmcore", the > runtime > "log" command does not use any VMCOREINFO entries that happen to be attached > to a dumpfile. > Since crash has the vmlinux debuginfo data available, it uses its own > interfaces to get > all kernel symbol and structure related information. > > But there is a little-used capability where the the vmlinux file is not > required, > but rather just the vmcore, in its "crash --log vmcore" feature. That > functionality > does require the VMCOREINFO entries to extract/dump the log, and exit. > Honestly I wish > I had never even introduced that feature. And I wonder if it were deprecated, > would anybody care? > > However, your question is highly relevant to the makedumpfile(8) facility > for its "makedumpfile --dump-dmesg" option. Since it doesn't have the > luxury of a vmlinux file, it needs all of the VMCOREINF_xxx items. Kazuhito > Hagio is the makedumpfile maintainer, and since he is the primary customer > of the VMCOREINFO entries, he would be a better person to answer your > question. > > That being said, due the sheer number VMCOREINFO entries required, I like > your idea of providing a single version number. But I defer to Kazu for > his preference. > > Thanks, > Dave > > > > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH v2] Determine the ARM64 kernel's Pointer Authentication mask value by reading the new KERNELPACMASK vmcoreinfo entry.
- Original Message -
...
>
> 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.
Just to be clear then, your v2 patch set should be OK to check in -- except
for this call to is_kernel_text():
> And then when trying to determine whether the current stack pointer is
> pointing to an in-kernel exception frame, the possible regs->pc and
regs[30]
> values are both transformed with the mask, so it seems that both of them
> will have been obfuscated by the processor when creating the frame on
> the stack:
>
>static int
>arm64_is_kernel_exception_frame(struct bt_info *bt, ulong stkptr)
>{
>struct arm64_pt_regs *regs;
>struct machine_specific *ms = machdep->machspec;
>
>regs = (struct arm64_pt_regs
*)>stackbuf[(ulong)(STACK_OFFSET_TYPE(stkptr))];
>
>if (INSTACK(regs->sp, bt) && INSTACK(regs->regs[29], bt) &&
>!(regs->pstate & (0xULL | PSR_MODE32_BIT))
&&
> > is_kernel_text(regs->pc | ms->CONFIG_ARM64_KERNELPACMASK) &&
Yes good catch. Masking can be removed from here.
Can you please confirm?
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH v2] Determine the ARM64 kernel's Pointer Authentication mask value by reading the new KERNELPACMASK vmcoreinfo entry.
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
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH v2] Determine the ARM64 kernel's Pointer Authentication mask value by reading the new KERNELPACMASK vmcoreinfo entry.
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@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
