Re: kexec does not work for kernel version with patch level >= 256

From: ebiederm@xmission.com (Eric W. Biederman)
To: Liu Tao <ltao@redhat.com>
Cc: Greg KH <gregkh@linuxfoundation.org>, Baoquan He <bhe@redhat.com>,
	Patrick Sung <patricksung@gmail.com>,
	sashal@kernel.org, kexec@lists.infradead.org,
	RuiRui Yang <dyoung@redhat.com>,
	horms@verge.net.au
Subject: Re: kexec does not work for kernel version with patch level >= 256
Date: Wed, 07 Apr 2021 12:23:25 -0500	[thread overview]
Message-ID: <m1sg42ggaa.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <CAO7dBbU=Q7yMKv-Hp8cUxgPffE=vxtKYvfP7NLKejf-Q8x+H=w@mail.gmail.com> (Liu Tao's message of "Tue, 6 Apr 2021 18:45:37 +0800")

Liu Tao <ltao@redhat.com> writes:

> Hello Eric,
>
> Please correct me if I'm wrong. After my research, I found that the
> KERNEL_VERSION
> check cannot be removed.
>
> In x86_64 case, function get_kernel_page_offset set different hard coded
> values into
> elf_info->page_offset according to KERNEL_VERSION, then in function
> get_kernel_vaddr_and_size,
> elf_info->page_offset gets refreshed by reading program segments of
> /proc/kcore.
> The refresh can fail when KASLR is off, thus the hard coded values are
> still needed as pre-set
> default values.

I see that the code is conditional upon KASLR, but I don't see any
particular reason why the code in get_kernel_vaddr_and_size is
conditional upon KASLR.

Skimming through arch/x86/kernel/vmlinux.lds.S and fs/proc/kcore.c I
don't see anything that is ASLR specific.  So everything should work
simply by removing the unnecessary gate on the presence of the
page_address_base symbol.

I suspect the code will even correctly compute PAGE_OFFSET on all
architectures, but we don't need to go that far to remove our use of the
kernel version.

> In addition, If I set a wrong value in elf_info->page_offset, readelf -l
> vmcore will give the value I set,
> reading symbols in crash-utility is not affected.

Especially if the reading the symbols is not affected by a wrong value
just auto-detecting the value really seems to make the most sense.

> From my point of view, extending the patch number from 8bit to 16bit is the
> solution. Any thoughts?

My thought is that in general the kernel version can not be depended
upon for anything as there exist enterprise kernels that get feature
backports.  So there very easily could be a kernel where the kernel
version does not accurately reflect what is going on.  So unless we can
say with certainty that there is no other way to detect the base address
of the kernel we really don't want to use the kernel version.

Right now it just looks like one all that is necessary is the removal of
an unnecessary if check.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec