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@nec.com>
> *Date: *Wednesday, November 22, 2023 at 12:01 PM
> *To: *Matt Suiche <matt.suiche@magnetforensics.com>,
> devel@lists.crash-utility.osci.io <devel@lists.crash-utility.osci.io>
> *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 ¡Vkaslr=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.
>