[Fastboot] correction to compat_sys_kexec_load

[Sharyathi Nagesh]

Hi
While testing with kexec tool, I observed some problems. When
application (kexec) is 32 bit and kernel is 64 bit I observed that
loading crash kernel works without any issues but unloading crash kernel
fails.
--------------------------------------------------------
running strace over 'kexec -u -p'
show the problem to be with sys_kexec_load() call

sys_kexec_load(0, 0, 0, 0x1, 0) = -1 EINVAL (Invalid argument)
write(2, "kexec_load (0 segments) failed: "..., 49
kexec_load (0 segments) failed: Invalid argument
) = 4
--------------------------------------------------------

This is patch to fix the problem, I think kernel code had a typo where in:
if((flags & KEXEC_ARCH_MASK) == KEXEC_ARCH) was used instead of
if((flags & KEXEC_ARCH_MASK) != KEXEC_ARCH)

This patch takes care of that, I have tested the patch it worked fine
for me. Please review the patch and let me know of your views. This
patch is based on linux-2.6.26-rc3.

Thanks
Yeehaw


-------------- next part --------------
A non-text attachment was scrubbed...
Name: compat_sys_kexec_correction.patch
Type: text/x-patch
Size: 596 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/fastboot/attachments/20080523/54aa1eb3/attachment.bin

[Eric W. Biederman]

Hi
While testing with kexec tool, I observed some problems. When application
(kexec) is 32 bit and kernel is 64 bit I observed that loading crash kernel
works without any issues but unloading crash kernel fails.
--------------------------------------------------------
running strace over 'kexec -u -p'
show the problem to be with sys_kexec_load() call
sys_kexec_load(0, 0, 0, 0x1, 0) = -1 EINVAL (Invalid argument)
write(2, "kexec_load (0 segments) failed: "..., 49
kexec_load (0 segments) failed: Invalid argument
) = 4

Yes. This is a bug. Although not in the kernel implementation.

--------------------------------------------------------
if((flags & KEXEC_ARCH_MASK) == KEXEC_ARCH) was used instead of
if((flags & KEXEC_ARCH_MASK) != KEXEC_ARCH)

Nope. We do the latter check after we have fixed up the arguments
and call sys_kexec_load. The check really is meant to filter out
KEXEC_ARCH_DEFAULT.

This patch takes care of that, I have tested the patch it worked fine for
me. Please review the patch and let me know of your views. This patch is based
on linux-2.6.26-rc3.

That patch as it exists is actively bad. It removes the check for a really
nasty gotcha if someone passes in KEXEC_ARCH_DEFAULT in 32bit mode. Code
expecting a 32bit handoff and getting a 64bit handoff will explode in fun
ways. You happened to test the one corner case where this does not matter.

What we need to do is fix /sbin/kexec to pass in the correct
architecture of the kernel for unload as it does for load.

Eric

[Bernhard Walle]

Post by Eric W. Biederman
What we need to do is fix /sbin/kexec to pass in the correct
architecture of the kernel for unload as it does for load.

How should it know that it unloads a 32 bit kernel on a 64 bit system?
It doesn't have access to the kernel any more once it has been loaded.



Bernhard

PS: My mail server complains that maneesh at in.ltcfwd.linux.ibm.com is
invalid because "Recipient address rejected: Domain not found". Maybe
some of the other IBM guys in Cc can take a look at this ... I just
removed that address from Cc for now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/fastboot/attachments/20080523/37dd88d7/attachment.pgp

[Eric W. Biederman]

Post by Bernhard Walle

Post by Eric W. Biederman
What we need to do is fix /sbin/kexec to pass in the correct
architecture of the kernel for unload as it does for load.

How should it know that it unloads a 32 bit kernel on a 64 bit system?
It doesn't have access to the kernel any more once it has been loaded.

The architecture parameter is the architecture of the running kernel
that implements sys_kexec_load.

Because it is a pain for testing and in general impossible we don't
change cpu modes during a kexec. So a 32bit caller of sys_kexec_load
will need to passing in different code if it is running on a 32bit or
a 64bit kernel.

The trampoline code in /sbin/kexec does change modes on x86 when
appropriate.

Caring if you know the architecture in the unload case is a bit
silly. As there is no real justification for it. At this
point getting user space fixed so that it works on older kernels
seems important.

Eric

[Bernhard Walle]

Post by Eric W. Biederman
As there is no real justification for it. At this
point getting user space fixed so that it works on older kernels
seems important.

http://article.gmane.org/gmane.linux.kernel.kexec/1534 should fix this.

[Sharyathi Nagesh]

Bernhard/Eric
Thanks for helping with this. kexec patch has been submitted up stream
Thanks
Yeehaw

Post by Bernhard Walle

Post by Eric W. Biederman
As there is no real justification for it. At this
point getting user space fixed so that it works on older kernels
seems important.

http://article.gmane.org/gmane.linux.kernel.kexec/1534 should fix this.