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

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

[Patrick Sung]

Hello all,

I am using the 4.9 long term kernel which is currently at 4.9.262.
When using this kernel with kexec-tools it prints out this error

  Unsupported utsname.release: 4.9.262
  Cannot load <kdump images path>

A quick search in the code shows that kexec/kernel_version.c doing this check:

  if (major >= 256 || minor >= 256 || patch >= 256) {

and also in kexec/kexec.h
  #define KERNEL_VERSION(major, minor, patch) \
    (((major) << 16) | ((minor) << 8) | patch)

which explains the reason for the range check in kernel_version.c

Increasing the number of bits allowed in "patch" seems to fix the issue.

Thanks,
Patrick

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

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

[Baoquan He]

On 03/24/21 at 12:28pm, Patrick Sung wrote:
> Hello all,
> 
> I am using the 4.9 long term kernel which is currently at 4.9.262.
> When using this kernel with kexec-tools it prints out this error
> 
>   Unsupported utsname.release: 4.9.262
>   Cannot load <kdump images path>
> 
> A quick search in the code shows that kexec/kernel_version.c doing this check:
> 
>   if (major >= 256 || minor >= 256 || patch >= 256) {
> 
> and also in kexec/kexec.h
>   #define KERNEL_VERSION(major, minor, patch) \
>     (((major) << 16) | ((minor) << 8) | patch)

Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
does cause the problem. I am not very sure about the longterm kernel
version numbering, maybe we can leave 16 bits for for patch number to
avoid the longterm kernel issue?

Is there document telling the longterm kernel version numbering, or any
pointer?

Thanks
Baoquan

> 
> which explains the reason for the range check in kernel_version.c
> 
> Increasing the number of bits allowed in "patch" seems to fix the issue.
> 
> Thanks,
> Patrick
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


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

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

[Patrick Sung]

On Wed, Mar 31, 2021 at 10:47 AM Baoquan He <bhe@redhat.com> wrote:
>
> On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > Hello all,
> >
> > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > When using this kernel with kexec-tools it prints out this error
> >
> >   Unsupported utsname.release: 4.9.262
> >   Cannot load <kdump images path>
> >
> > A quick search in the code shows that kexec/kernel_version.c doing this check:
> >
> >   if (major >= 256 || minor >= 256 || patch >= 256) {
> >
> > and also in kexec/kexec.h
> >   #define KERNEL_VERSION(major, minor, patch) \
> >     (((major) << 16) | ((minor) << 8) | patch)
>
> Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
> does cause the problem. I am not very sure about the longterm kernel
> version numbering, maybe we can leave 16 bits for for patch number to
> avoid the longterm kernel issue?
>
> Is there document telling the longterm kernel version numbering, or any
> pointer?
>
Actually I found that the mainline kernel clamp the "patch" version to 255

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0

> Thanks
> Baoquan
>
> >
> > which explains the reason for the range check in kernel_version.c
> >
> > Increasing the number of bits allowed in "patch" seems to fix the issue.
> >
> > Thanks,
> > Patrick
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> >
>

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

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

[Baoquan He]

On 03/31/21 at 11:04am, Patrick Sung wrote:
> On Wed, Mar 31, 2021 at 10:47 AM Baoquan He <bhe@redhat.com> wrote:
> >
> > On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > > Hello all,
> > >
> > > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > > When using this kernel with kexec-tools it prints out this error
> > >
> > >   Unsupported utsname.release: 4.9.262
> > >   Cannot load <kdump images path>
> > >
> > > A quick search in the code shows that kexec/kernel_version.c doing this check:
> > >
> > >   if (major >= 256 || minor >= 256 || patch >= 256) {
> > >
> > > and also in kexec/kexec.h
> > >   #define KERNEL_VERSION(major, minor, patch) \
> > >     (((major) << 16) | ((minor) << 8) | patch)
> >
> > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
> > does cause the problem. I am not very sure about the longterm kernel
> > version numbering, maybe we can leave 16 bits for for patch number to
> > avoid the longterm kernel issue?
> >
> > Is there document telling the longterm kernel version numbering, or any
> > pointer?
> >
> Actually I found that the mainline kernel clamp the "patch" version to 255
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0

Yeah, mainline kernel use below formula to construct kernel version.
Seems longterm kernel takes a different way. While it's understandable
that Longterm kernel using a larger patch number since it will evolve
evolve for a longer time to get in bug fixes. Maybe we should enlarge
patch number to 16 bits?

echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \                                                                        
        ((c) > 255 ? 255 : (c)))';

By the way, it calls 'a' version number, 'b' patch level, 'c' sub-level
in Makefile of kernel?

> 
> > Thanks
> > Baoquan
> >
> > >
> > > which explains the reason for the range check in kernel_version.c
> > >
> > > Increasing the number of bits allowed in "patch" seems to fix the issue.
> > >
> > > Thanks,
> > > Patrick
> > >
> > > _______________________________________________
> > > kexec mailing list
> > > kexec@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/kexec
> > >
> >
> 


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

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

[Baoquan He]

Add Sasha and Greg to the CC list.

On 03/31/21 at 11:48am, Baoquan He wrote:
> On 03/31/21 at 11:04am, Patrick Sung wrote:
> > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He <bhe@redhat.com> wrote:
> > >
> > > On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > > > Hello all,
> > > >
> > > > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > > > When using this kernel with kexec-tools it prints out this error
> > > >
> > > >   Unsupported utsname.release: 4.9.262
> > > >   Cannot load <kdump images path>
> > > >
> > > > A quick search in the code shows that kexec/kernel_version.c doing this check:
> > > >
> > > >   if (major >= 256 || minor >= 256 || patch >= 256) {
> > > >
> > > > and also in kexec/kexec.h
> > > >   #define KERNEL_VERSION(major, minor, patch) \
> > > >     (((major) << 16) | ((minor) << 8) | patch)
> > >
> > > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
> > > does cause the problem. I am not very sure about the longterm kernel
> > > version numbering, maybe we can leave 16 bits for for patch number to
> > > avoid the longterm kernel issue?
> > >
> > > Is there document telling the longterm kernel version numbering, or any
> > > pointer?
> > >
> > Actually I found that the mainline kernel clamp the "patch" version to 255
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
> 
> Yeah, mainline kernel use below formula to construct kernel version.
> Seems longterm kernel takes a different way. While it's understandable
> that Longterm kernel using a larger patch number since it will evolve
> evolve for a longer time to get in bug fixes. Maybe we should enlarge
> patch number to 16 bits?
> 
> echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \                                                                        
>         ((c) > 255 ? 255 : (c)))';

Should we also need to do the the same thing in kexec-tools utility, to
clamp the sub-level to 255? And the sub-level number is not so important
that we can do the clamping and won't cause any issue?

Thanks
Baoquan

> 
> By the way, it calls 'a' version number, 'b' patch level, 'c' sub-level
> in Makefile of kernel?
> 
> > 
> > > Thanks
> > > Baoquan
> > >
> > > >
> > > > which explains the reason for the range check in kernel_version.c
> > > >
> > > > Increasing the number of bits allowed in "patch" seems to fix the issue.
> > > >
> > > > Thanks,
> > > > Patrick
> > > >
> > > > _______________________________________________
> > > > kexec mailing list
> > > > kexec@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/kexec
> > > >
> > >
> > 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


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

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

[Greg KH]

On Wed, Mar 31, 2021 at 04:03:24PM +0800, Baoquan He wrote:
> Add Sasha and Greg to the CC list.
> 
> On 03/31/21 at 11:48am, Baoquan He wrote:
> > On 03/31/21 at 11:04am, Patrick Sung wrote:
> > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He <bhe@redhat.com> wrote:
> > > >
> > > > On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > > > > Hello all,
> > > > >
> > > > > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > > > > When using this kernel with kexec-tools it prints out this error
> > > > >
> > > > >   Unsupported utsname.release: 4.9.262
> > > > >   Cannot load <kdump images path>
> > > > >
> > > > > A quick search in the code shows that kexec/kernel_version.c doing this check:
> > > > >
> > > > >   if (major >= 256 || minor >= 256 || patch >= 256) {
> > > > >
> > > > > and also in kexec/kexec.h
> > > > >   #define KERNEL_VERSION(major, minor, patch) \
> > > > >     (((major) << 16) | ((minor) << 8) | patch)
> > > >
> > > > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
> > > > does cause the problem. I am not very sure about the longterm kernel
> > > > version numbering, maybe we can leave 16 bits for for patch number to
> > > > avoid the longterm kernel issue?
> > > >
> > > > Is there document telling the longterm kernel version numbering, or any
> > > > pointer?
> > > >
> > > Actually I found that the mainline kernel clamp the "patch" version to 255
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
> > 
> > Yeah, mainline kernel use below formula to construct kernel version.
> > Seems longterm kernel takes a different way. While it's understandable
> > that Longterm kernel using a larger patch number since it will evolve
> > evolve for a longer time to get in bug fixes. Maybe we should enlarge
> > patch number to 16 bits?
> > 
> > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \                                                                        
> >         ((c) > 255 ? 255 : (c)))';
> 
> Should we also need to do the the same thing in kexec-tools utility, to
> clamp the sub-level to 255? And the sub-level number is not so important
> that we can do the clamping and won't cause any issue?

If you can enlarge your "c" number to be 16bits, please do so.  We
couldn't do that in the kernel source as it would break an existing
user/kernel api :(

thanks,

greg k-h

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

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

[Eric W. Biederman]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Wed, Mar 31, 2021 at 04:03:24PM +0800, Baoquan He wrote:
>> Add Sasha and Greg to the CC list.
>> 
>> On 03/31/21 at 11:48am, Baoquan He wrote:
>> > On 03/31/21 at 11:04am, Patrick Sung wrote:
>> > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He <bhe@redhat.com> wrote:
>> > > >
>> > > > On 03/24/21 at 12:28pm, Patrick Sung wrote:
>> > > > > Hello all,
>> > > > >
>> > > > > I am using the 4.9 long term kernel which is currently at 4.9.262.
>> > > > > When using this kernel with kexec-tools it prints out this error
>> > > > >
>> > > > >   Unsupported utsname.release: 4.9.262
>> > > > >   Cannot load <kdump images path>
>> > > > >
>> > > > > A quick search in the code shows that kexec/kernel_version.c doing this check:
>> > > > >
>> > > > >   if (major >= 256 || minor >= 256 || patch >= 256) {
>> > > > >
>> > > > > and also in kexec/kexec.h
>> > > > >   #define KERNEL_VERSION(major, minor, patch) \
>> > > > >     (((major) << 16) | ((minor) << 8) | patch)
>> > > >
>> > > > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
>> > > > does cause the problem. I am not very sure about the longterm kernel
>> > > > version numbering, maybe we can leave 16 bits for for patch number to
>> > > > avoid the longterm kernel issue?
>> > > >
>> > > > Is there document telling the longterm kernel version numbering, or any
>> > > > pointer?
>> > > >
>> > > Actually I found that the mainline kernel clamp the "patch" version to 255
>> > > 
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
>> > 
>> > Yeah, mainline kernel use below formula to construct kernel version.
>> > Seems longterm kernel takes a different way. While it's understandable
>> > that Longterm kernel using a larger patch number since it will evolve
>> > evolve for a longer time to get in bug fixes. Maybe we should enlarge
>> > patch number to 16 bits?
>> > 
>> > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \                                                                        
>> >         ((c) > 255 ? 255 : (c)))';
>> 
>> Should we also need to do the the same thing in kexec-tools utility, to
>> clamp the sub-level to 255? And the sub-level number is not so important
>> that we can do the clamping and won't cause any issue?
>
> If you can enlarge your "c" number to be 16bits, please do so.  We
> couldn't do that in the kernel source as it would break an existing
> user/kernel api :(

The code in kexec certainly can.  The function kernel_version() returns
a long.

However.  I think the code in kexec can do better.

There are only 4 uses of KERNEL_VERSION in the tree and only one of them
is testing for a case that would apply to kernel versions that are being
maintained.

AKA  I think checks for 3.15 and 2.6.27 we can just delete.

The checks for 3.15 are about command line size and are actively wrong.
As checking the running kernel to find the version of the kernel that
is being loaded is not reliable.

Which leaves only one check and I think the information needed is
X86_64_PAGE_OFFSET.  I think that can be obtained directly by
reading /proc/kcore instead of guessing it from the kernel version.

Does anyone want to try that?  I admit it is a bit more work than
changing the macro to just add more bits to the patch level
but it is would be more robust long term.

Eric

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

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

[Eric W. Biederman]

Liu Tao <ltao@redhat.com> writes:

> Hello Eric,
>
> I'd like to have a try on this issue.
> Since I'm not very familiar with the related code, maybe I need to spend a
> little more time on it.

Please give it a shot.

Getting rid of explicit kernel version checks would be wonderful and
prevent future problems as well.

Eric

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

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

[Eric W. Biederman]

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