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>
> *Date: *Wednesday, November 22, 2023 at 12:01 PM
> *To: *Matt Suiche <matt.suiche(a)magnetforensics.com>,
> devel(a)lists.crash-utility.osci.io <devel(a)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 –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.
>