All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Sharyathi Nagesh <sharyath@in.ibm.com>
Cc: akpm@osdl.org, mohd.omar@in.ibm.com, IndhuDurai@in.ibm.com,
	maneesh@in.ltcfwd.linux.ibm.com,
	Kexec Mailing List <kexec@lists.infradead.org>,
	fastboot@lists.osdl.org, linux-kernel@vger.kernel.org,
	mohan@in.ibm.com, sachinp@in.ibm.com
Subject: Re: correction to compat_sys_kexec_load
Date: Fri, 23 May 2008 13:14:42 -0700	[thread overview]
Message-ID: <m1ve144w25.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <4836AC3C.3090005@in.ibm.com> (Sharyathi Nagesh's message of "Fri, 23 May 2008 17:06:28 +0530")

Sharyathi Nagesh <sharyath@in.ibm.com> writes:

> 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.

> --------------------------------------------------------
>
> 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)

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

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

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Sharyathi Nagesh <sharyath@in.ibm.com>
Cc: linux-kernel@vger.kernel.org, fastboot@lists.osdl.org,
	akpm@osdl.org, maneesh@in.ltcfwd.linux.ibm.com, mohan@in.ibm.com,
	sachinp@in.ibm.com, mohd.omar@in.ibm.com, IndhuDurai@in.ibm.com,
	Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: correction to compat_sys_kexec_load
Date: Fri, 23 May 2008 13:14:42 -0700	[thread overview]
Message-ID: <m1ve144w25.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <4836AC3C.3090005@in.ibm.com> (Sharyathi Nagesh's message of "Fri, 23 May 2008 17:06:28 +0530")

Sharyathi Nagesh <sharyath@in.ibm.com> writes:

> 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.

> --------------------------------------------------------
>
> 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)

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

  reply	other threads:[~2008-05-23 20:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-23 11:36 correction to compat_sys_kexec_load Sharyathi Nagesh
2008-05-23 20:14 ` Eric W. Biederman [this message]
2008-05-23 20:14   ` Eric W. Biederman
2008-05-23 21:33   ` Bernhard Walle
2008-05-23 21:33     ` Bernhard Walle
2008-05-24  0:36     ` Eric W. Biederman
2008-05-24  0:36       ` Eric W. Biederman
2008-05-26 20:32       ` Bernhard Walle
2008-05-26 20:32         ` Bernhard Walle
2008-05-28  4:39         ` Sharyathi Nagesh
2008-05-28  4:39           ` Sharyathi Nagesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1ve144w25.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=IndhuDurai@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=fastboot@lists.osdl.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ltcfwd.linux.ibm.com \
    --cc=mohan@in.ibm.com \
    --cc=mohd.omar@in.ibm.com \
    --cc=sachinp@in.ibm.com \
    --cc=sharyath@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.