[Crash-utility] Re: Google Container OS and crash 8.0.4

On 2024/01/15 22:37, Matt Suiche wrote: No. I saw a kernel patch that removes module_load_offset [1] and will affect the crash-utility, so I was thinking that it would be better to address the issue together when it comes.. [1] https://lore.kernel.org/linux-mm/20230918072955.2507221-5-rppt@kernel.org/ Thanks, Kazu > > Thanks, > > From: Matt Suiche <matt.suiche(a)magnetforensics.com&gt; > Date: Wednesday, November 29, 2023 at 3:26 PM > To: HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt;, devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; > Subject: Re: [Crash-utility] Google Container OS and crash 8.0.4 > Apparently, CONFIG_KALLSYMS_ALL is not set in COS kernel > > Sent from my mobile device. > ________________________________ > From: Matt Suiche <matt.suiche(a)magnetforensics.com&gt; > Sent: Wednesday, November 29, 2023 4:40:55 PM > To: HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com>; devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; > Subject: Re: [Crash-utility] Google Container OS and crash 8.0.4 > > Yes, it would probably make more sense. You can also probably use _stext instead of module_load_offset too to compare the values as an assertion check. > > Sent from my mobile device. > ________________________________ > From: HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt; > Sent: Wednesday, November 29, 2023 4:29 AM > To: Matt Suiche <matt.suiche(a)magnetforensics.com>; devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; > Subject: Re: [Crash-utility] Google Container OS and crash 8.0.4 > > On 2023/11/22 18:04, Matt Suiche wrote: >> Sounds like this is the issue. Module_load_offset is not present, same >> with init_task though. >> >> root@instance-2:~# grep -e _stext -e module_load_offset -e init_task >> /proc/kallsyms >> ffffffff89000000 T _stext >> ffffffff8909e280 t ptrace_init_task >> ffffffff891c6af0 T ftrace_graph_init_task >> ffffffff89245ea0 T perf_event_init_task >> ffffffff8aba3b46 T rcu_init_tasks_generic >> root@instance-2:~# > > Yes, but I don't see the reason why it's not present in /proc/kallsyms, > although it's present in the vmlinux.. > > Recent kernels have vmcoreinfo in /proc/kcore, maybe we can use the > KERNELOFFSET value instead of the module_load_offset symbol to determine > whether KASLR is enabled. I might try it when I have time. > > Thanks, > Kazu > >> >> *From: *HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt; >> *Date: *Wednesday, November 22, 2023 at 12:01 PM >> *To: *Matt Suiche <matt.suiche(a)magnetforensics.com&gt;, >> devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; >> *Subject: *EXTERNAL SENDER Re: [Crash-utility] Google Container OS and >> crash 8.0.4 >> >> On 2023/11/22 15:41, Matt Suiche wrote: >>> Good point, enough the –kaslr=auto option worked well. Same when I passed --kaslr=0x8000000 >> >> Good news. >> >> apparently module_load_offset symbol is needed in /proc/kallsyms to >> enable the KASLR detection. I see it in the vmlinux. >> >> $ nm vmlinux-cos-5.15.133+ | grep module_load_offset >> ffffffff82d83350 b module_load_offset >> >> Is it (and _stext) found in /proc/kallsyms? like >> >> # grep -e _stext -e module_load_offset /proc/kallsyms >> ffffffffa0e00000 T _stext >> ffffffffa3aafab8 b module_load_offset >> >> >> PS. I will be out for the rest of this week, back next week. >> >> Thanks, >> Kazu >> >> This email including any attachments may contain confidential material >> for the sole use of the intended recipient. If you are not the intended >> recipient please immediately notify the sender by reply email, >> permanently delete this message and do not forward it or any part of it >> to anyone else. >> > > This email including any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient please immediately notify the sender by reply email, permanently delete this message and do not forward it or any part of it to anyone else. > > > > Thanks, > > *From: *Matt Suiche <matt.suiche(a)magnetforensics.com&gt; > *Date: *Wednesday, November 29, 2023 at 3:26 PM > *To: *HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt;, > devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; > *Subject: *Re: [Crash-utility] Google Container OS and crash 8.0.4 > > Apparently, CONFIG_KALLSYMS_ALL is not set in COS kernel > > Sent from my mobile device. > > ------------------------------------------------------------------------ > > *From:*Matt Suiche <matt.suiche(a)magnetforensics.com&gt; > *Sent:* Wednesday, November 29, 2023 4:40:55 PM > *To:* HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com>; > devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; > *Subject:* Re: [Crash-utility] Google Container OS and crash 8.0.4 > > Yes, it would probably make more sense. You can also probably use _stext > instead of module_load_offset too to compare the values as an assertion > check. > > Sent from my mobile device. > > ------------------------------------------------------------------------ > > *From:*HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt; > *Sent:* Wednesday, November 29, 2023 4:29 AM > *To:* Matt Suiche <matt.suiche(a)magnetforensics.com>; > devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; > *Subject:* Re: [Crash-utility] Google Container OS and crash 8.0.4 > > On 2023/11/22 18:04, Matt Suiche wrote: >> Sounds like this is the issue. Module_load_offset is not present, same >> with init_task though. >> >> root@instance-2:~# grep -e _stext -e module_load_offset -e init_task >> /proc/kallsyms >> ffffffff89000000 T _stext >> ffffffff8909e280 t ptrace_init_task >> ffffffff891c6af0 T ftrace_graph_init_task >> ffffffff89245ea0 T perf_event_init_task >> ffffffff8aba3b46 T rcu_init_tasks_generic >> root@instance-2:~# > > Yes, but I don't see the reason why it's not present in /proc/kallsyms, > although it's present in the vmlinux.. > > Recent kernels have vmcoreinfo in /proc/kcore, maybe we can use the > KERNELOFFSET value instead of the module_load_offset symbol to determine > whether KASLR is enabled.  I might try it when I have time. > > Thanks, > Kazu > >> >> *From: *HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab(a)nec.com&gt; >> *Date: *Wednesday, November 22, 2023 at 12:01 PM >> *To: *Matt Suiche <matt.suiche(a)magnetforensics.com&gt;, >> devel(a)lists.crash-utility.osci.io <devel(a)lists.crash-utility.osci.io&gt; >> *Subject: *EXTERNAL SENDER Re: [Crash-utility] Google Container OS and >> crash 8.0.4 >> >> On 2023/11/22 15:41, Matt Suiche wrote: >>> Good point, enough the –kaslr=auto option worked well. Same when I passed --kaslr=0x8000000 >> >> Good news. >> >> apparently module_load_offset symbol is needed in /proc/kallsyms to >> enable the KASLR detection.  I see it in the vmlinux. >> >> $ nm vmlinux-cos-5.15.133+ | grep module_load_offset >> ffffffff82d83350 b module_load_offset >> >> Is it (and _stext) found in /proc/kallsyms? like >> >> # grep -e _stext -e module_load_offset /proc/kallsyms >> ffffffffa0e00000 T _stext >> ffffffffa3aafab8 b module_load_offset >> >> >> PS. I will be out for the rest of this week, back next week. >> >> Thanks, >> Kazu >> >> This email including any attachments may contain confidential material >> for the sole use of the intended recipient. If you are not the intended >> recipient please immediately notify the sender by reply email, >> permanently delete this message and do not forward it or any part of it >> to anyone else. >> > > This email including any attachments may contain confidential material > for the sole use of the intended recipient. If you are not the intended > recipient please immediately notify the sender by reply email, > permanently delete this message and do not forward it or any part of it > to anyone else. > >