From: Vivek Goyal <vgoyal@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: kexec@lists.infradead.org
Subject: Re: Kexec command line length
Date: Tue, 29 Jan 2008 10:41:04 -0500 [thread overview]
Message-ID: <20080129154104.GA12219@redhat.com> (raw)
In-Reply-To: <20080129010122.GA11935@hmsreliant.think-freely.org>
On Mon, Jan 28, 2008 at 08:01:22PM -0500, Neil Horman wrote:
> On Mon, Jan 28, 2008 at 10:29:10PM +0100, Bernhard Walle wrote:
> > * Neil Horman <nhorman@tuxdriver.com> [2008-01-28 21:53]:
> > > return -1;
> > > }
> > >
> > > + if (setup_header.protocol_version >= 0x0206) {
> > > + if (command_line_len > setup_header.cmdline_size) {
> > > + dbgprintf("Kernel command line too long for kernel!\n");
> > > + return -1;
> > > + }
> > > + }
> > > +
> > > if (setup_header.protocol_version >= 0x0205) {
> > > relocatable_kernel = setup_header.relocatable_kernel;
> > > dbgprintf("bzImage is relocatable\n");
> >
> > I know that there was a kernel release with 2048 _and_ still the old
> > boot protocol, but wouldn't it be better to warn the user if the size
> > is beyond 256 and the old kernel is used? I think new kexec-tools
> > should still support old kernels without problems ...
> >
>
> I don't know how important that really is, but I don't see a particular problem
> with it either. From my reading of i386/boot.txt, versions prior to boot
> protocol 2.02 only supported a 256 bytes command line patch, so what if we just
> add an extra check in do_bzImage_load. If the protocol version of the boot
> header is lexx than 0x0202, then we fail if the command line length is more than
> 256 bytes. Note there are two other locations where we use a linux boot
> protocol header, but they are both constructed heders, not read headers, and use
> protocol version 2.03, which support 2048 byte command lines.
>
I think 2048 command line support came much later. I think it came between
version 2.05 and 2.06 (But somebody needs to dive into archive to verify).
Because command line size could go beyond 256, we introduced cmdline_size
parameter in version 2.06 to let a boot loader know.
What Bernanrd seems to be talking about a small window where boot protocol
was 2.05 but supported command line size was still 2048.
I think if we are loading any kernel older than 2.06 (and newer than
2.05?), and if command line size is greater than 256, we just might want to
give a debug warning to user, saying command line is great than 256 and kernel
does not tell me what's the supported command line size. (Somthing like that).
So it might look something like this.
if (protocol version > 2.06)
error user depending on cmdline_size;
else if (protocol version > 2.05 && protocol version < 2.06)
warn on cmdline being more than 256. We don't know for sure.
else
error out if cmdline is greater than 256
I am not very sure about the boundary version 2.05, somebody needs to
verify.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2008-01-29 15:44 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-14 13:43 Kexec command line length Neil Horman
2008-01-14 14:50 ` Bernhard Walle
2008-01-14 15:40 ` Neil Horman
2008-01-15 15:27 ` Vivek Goyal
2008-01-15 17:09 ` Neil Horman
2008-01-15 17:37 ` Vivek Goyal
2008-01-25 12:35 ` Neil Horman
2008-01-25 15:39 ` Vivek Goyal
2008-01-25 15:44 ` H. Peter Anvin
2008-01-25 19:50 ` Neil Horman
2008-01-25 19:54 ` H. Peter Anvin
2008-01-25 20:11 ` Neil Horman
2008-01-25 20:13 ` Vivek Goyal
2008-01-25 20:54 ` Neil Horman
2008-01-28 17:08 ` Neil Horman
2008-01-28 19:37 ` Vivek Goyal
2008-01-28 20:07 ` Neil Horman
2008-01-28 20:20 ` Vivek Goyal
2008-01-28 20:53 ` Neil Horman
2008-01-28 21:09 ` Vivek Goyal
2008-01-28 21:29 ` Bernhard Walle
2008-01-29 1:01 ` Neil Horman
2008-01-29 15:41 ` Vivek Goyal [this message]
2008-01-29 18:17 ` Bernhard Walle
2008-01-29 18:52 ` Neil Horman
2008-01-29 19:57 ` Neil Horman
2008-01-30 20:53 ` Vivek Goyal
2008-01-30 20:59 ` Neil Horman
2008-01-30 21:08 ` Vivek Goyal
2008-01-30 21:18 ` Neil Horman
2008-01-30 21:45 ` Vivek Goyal
2008-01-31 0:10 ` Neil Horman
2008-01-31 7:16 ` Bernhard Walle
2008-02-12 21:11 ` Neil Horman
2008-02-18 3:14 ` Simon Horman
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=20080129154104.GA12219@redhat.com \
--to=vgoyal@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=nhorman@tuxdriver.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.