H. Peter Anvin wrote:
> Chris Wedgwood wrote:
>
>> On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote:
>>
>>> I think someone on the SYSLINUX mailing list already sent a patch to
>>> akpm to make 512 the default; making it configurable would be a
>>> better idea. Feel free to send your patch through me.
>>
>>
>> So we really need this to be a configuration option? We have too many
>> of those already.
>
>
> Maybe not. Another option would simply be to bump it up significantly
> (2x isn't really that much.) 4096, maybe.
>
> -hpa
>
Hello Peter, I've written a reply before but got no response...
The idea of putting arguments in initramfs is not practical,
since the whole idea is to have the same image of system and
affecting its behavior using the boot loader...
I would like to push forward the idea to extend the
command-line size...
All we need for start is an updated version of the "THE
LINUX/I386 BOOT PROTOCOL" document that states that in the
2.02+ protocol the boot loader should set cmd_line_ptr to a
pointer to a null terminated string without any size
restriction, specifying that the kernel will read as much as
it can.
After I get this update, I will try to work with GRUB and LILO
so that they will fix their implementation. Currently they
claim that they understand that they should truncate the
string to 256.
After that I will provide my simple patch for setting the
maximum size the kernel allocates in the configuration.
BTW: Do you know why the COMMAND_LINE_SIZE constant is located
in two separate include files?
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev wrote:
>
> Hello Peter, I've written a reply before but got no response...
>
> The idea of putting arguments in initramfs is not practical, since the
> whole idea is to have the same image of system and affecting its
> behavior using the boot loader...
>
No, you're wrong. The boot loader can synthesize an initramfs.
> I would like to push forward the idea to extend the command-line size...
>
> All we need for start is an updated version of the "THE LINUX/I386 BOOT
> PROTOCOL" document that states that in the 2.02+ protocol the boot
> loader should set cmd_line_ptr to a pointer to a null terminated string
> without any size restriction, specifying that the kernel will read as
> much as it can.
Already pushed to Andrew. I will follow it up with a patch to extend
the command line, at least to 512.
> After I get this update, I will try to work with GRUB and LILO so that
> they will fix their implementation. Currently they claim that they
> understand that they should truncate the string to 256.
>
> After that I will provide my simple patch for setting the maximum size
> the kernel allocates in the configuration.
>
> BTW: Do you know why the COMMAND_LINE_SIZE constant is located in two
> separate include files?
No, I don't. It could be because one is included from assembly code in
the i386 architecture.
-hpa
Thank you for the reply,
H. Peter Anvin wrote:
> Alon Bar-Lev wrote:
>
>>
>> Hello Peter, I've written a reply before but got no response...
>>
>> The idea of putting arguments in initramfs is not practical, since the
>> whole idea is to have the same image of system and affecting its
>> behavior using the boot loader...
>>
>
> No, you're wrong. The boot loader can synthesize an initramfs.
Hmm... Isn't it somewhat big change for them?
Do you mean that they can add a text file at root containing
the command-line?
It is not so good... Since currently many scripts looks at
/proc/cmdline and get the arguments they are interested in...
The initramfs will not allow this... And there is no access to
initramfs files after control is passed to root, since most
distributions erase its contents in order to free memory...
>
> Already pushed to Andrew. I will follow it up with a patch to extend
> the command line, at least to 512.
Thanks!!!
But why not making it a configuration option?
For example, I think it should be at least 1024...
Will this patch update the document?
If it does please don't specify maximum size,
The boot loader should be instructed to put unlimited
string... OK... there is no thing like unlimited, so max 16K :)
Only the kernel should truncate it to the right size.
Best Regards,
Alon Bar-Lev.
Hi,
what's the status of this? linux-2.6.14-rc3 still has 256 chars limit. A
quick fix to 1024 would help a lot. Other Platforms have up to 4096...
Greetings,
Georg
Hello Peter,
my first post didn't get any attention, maybe it was too short.
Here's a longer version:
[email protected] wrote on Sept. 6th, 2005:
[ wrt. COMMAND_LINE_SIZE=256 in linux/include/asm-i386/setup.h and
linux/include/asm-i386/param.h ]
>> I would like to push forward the idea to extend the command-line size...
> [...]
> Already pushed to Andrew. I will follow it up with a patch to extend
> the command line, at least to 512.
I would like to know the status of this. In linux-2.6.14-rc3 the
COMMAND_LINE_SIZE is still 256 chars long.
Here's a patch to fix that to 1024.
Signed-off-by: Georg Lippold <[email protected]>
--- linux/include/asm-i386/param.h~ 2005-09-21 23:32:23.000000000 +0200
+++ linux/include/asm-i386/param.h 2005-10-10 14:39:34.000000000 +0200
@@ -18,6 +18,6 @@
#endif
#define MAXHOSTNAMELEN 64 /* max length of hostname */
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024
#endif
--- linux/include/asm-i386/setup.h~ 2005-10-10 14:39:18.000000000 +0200
+++ linux/include/asm-i386/setup.h 2005-10-10 14:39:45.000000000 +0200
@@ -17,7 +17,7 @@
#define MAX_NONPAE_PFN (1 << 20)
#define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024
#define OLD_CL_MAGIC_ADDR 0x90020
#define OLD_CL_MAGIC 0xA33F
On 10/10/05, Georg Lippold <[email protected]> wrote:
> Hello Peter,
>
> my first post didn't get any attention, maybe it was too short.
> Here's a longer version:
>
> [email protected] wrote on Sept. 6th, 2005:
>
> [ wrt. COMMAND_LINE_SIZE=256 in linux/include/asm-i386/setup.h and
> linux/include/asm-i386/param.h ]
>
> >> I would like to push forward the idea to extend the command-line size...
> > [...]
> > Already pushed to Andrew. I will follow it up with a patch to extend
> > the command line, at least to 512.
>
> I would like to know the status of this. In linux-2.6.14-rc3 the
> COMMAND_LINE_SIZE is still 256 chars long.
>
> Here's a patch to fix that to 1024.
>
What about the other archs ?
include/asm/setup.h:#define COMMAND_LINE_SIZE 256
include/asm/param.h:#define COMMAND_LINE_SIZE 256
include/asm-m68knommu/setup.h:#define COMMAND_LINE_SIZE 512
include/asm-powerpc/setup.h:#define COMMAND_LINE_SIZE 512
include/asm-sh/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-um/setup.h:#define COMMAND_LINE_SIZE 4096
include/asm-parisc/setup.h:#define COMMAND_LINE_SIZE 1024
include/asm-x86_64/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-xtensa/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-alpha/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-arm26/setup.h:#define COMMAND_LINE_SIZE 1024
include/asm-h8300/setup.h:#define COMMAND_LINE_SIZE 512
include/asm-sparc/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-i386/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-i386/param.h:#define COMMAND_LINE_SIZE 256
include/asm-cris/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-m32r/setup.h:#define COMMAND_LINE_SIZE (512)
include/asm-ia64/setup.h:#define COMMAND_LINE_SIZE 512
include/asm-m68k/setup.h:#define COMMAND_LINE_SIZE CL_SIZE
include/asm-mips/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-mips/bootinfo.h:#define CL_SIZE
COMMAND_LINE_SIZE
include/asm-s390/setup.h:#define COMMAND_LINE_SIZE 896
include/asm-v850/setup.h:#define COMMAND_LINE_SIZE 512
include/asm-sh64/setup.h:#define COMMAND_LINE_SIZE 256
include/asm-arm/setup.h:#define COMMAND_LINE_SIZE 1024
include/asm-frv/param.h:#define COMMAND_LINE_SIZE 512
include/asm-sparc64/setup.h:#define COMMAND_LINE_SIZE 256
Would it make sense to make it 1024 everywhere (and maybe move it out
of arch specific files and just set it in one central place) ?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Hello,
1. Why don't you put this variable at config, and allow the user to
specify the length during configuration? I have a patch that does just
that.
2. THE MOST IMPORTANT task is to update the documentation at
i386/boot.txt so that it will state that boot protocol 2.02+ field
cmd_line_ptr should not be truncated and can be up to 4K bytes.
Also fix "The kernel command line is null-terminated string up to 255
characters long,..." this is good for the old boot protocol, but not
for the 2.02+ protocol.
Without this fix the bootloaders (Lilo, Grub) will not fix their
code... So that users will still will not be able to use > 256 command
line.
I've opened bug at Grub... and I wait for the documentation update so
that they will modify their behaviour of truncating the cmd_line_ptr
to 256.
Best Regards,
Alon Bar-Lev.
On 10/10/05, Jesper Juhl <[email protected]> wrote:
> On 10/10/05, Georg Lippold <[email protected]> wrote:
> > Hello Peter,
> >
> > my first post didn't get any attention, maybe it was too short.
> > Here's a longer version:
> >
> > [email protected] wrote on Sept. 6th, 2005:
> >
> > [ wrt. COMMAND_LINE_SIZE=256 in linux/include/asm-i386/setup.h and
> > linux/include/asm-i386/param.h ]
> >
> > >> I would like to push forward the idea to extend the command-line size...
> > > [...]
> > > Already pushed to Andrew. I will follow it up with a patch to extend
> > > the command line, at least to 512.
> >
> > I would like to know the status of this. In linux-2.6.14-rc3 the
> > COMMAND_LINE_SIZE is still 256 chars long.
> >
> > Here's a patch to fix that to 1024.
> >
>
> What about the other archs ?
>
> include/asm/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm/param.h:#define COMMAND_LINE_SIZE 256
> include/asm-m68knommu/setup.h:#define COMMAND_LINE_SIZE 512
> include/asm-powerpc/setup.h:#define COMMAND_LINE_SIZE 512
> include/asm-sh/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-um/setup.h:#define COMMAND_LINE_SIZE 4096
> include/asm-parisc/setup.h:#define COMMAND_LINE_SIZE 1024
> include/asm-x86_64/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-xtensa/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-alpha/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-arm26/setup.h:#define COMMAND_LINE_SIZE 1024
> include/asm-h8300/setup.h:#define COMMAND_LINE_SIZE 512
> include/asm-sparc/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-i386/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-i386/param.h:#define COMMAND_LINE_SIZE 256
> include/asm-cris/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-m32r/setup.h:#define COMMAND_LINE_SIZE (512)
> include/asm-ia64/setup.h:#define COMMAND_LINE_SIZE 512
> include/asm-m68k/setup.h:#define COMMAND_LINE_SIZE CL_SIZE
> include/asm-mips/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-mips/bootinfo.h:#define CL_SIZE
> COMMAND_LINE_SIZE
> include/asm-s390/setup.h:#define COMMAND_LINE_SIZE 896
> include/asm-v850/setup.h:#define COMMAND_LINE_SIZE 512
> include/asm-sh64/setup.h:#define COMMAND_LINE_SIZE 256
> include/asm-arm/setup.h:#define COMMAND_LINE_SIZE 1024
> include/asm-frv/param.h:#define COMMAND_LINE_SIZE 512
> include/asm-sparc64/setup.h:#define COMMAND_LINE_SIZE 256
>
> Would it make sense to make it 1024 everywhere (and maybe move it out
> of arch specific files and just set it in one central place) ?
>
>
> --
> Jesper Juhl <[email protected]>
> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
> Plain text mails only, please http://www.expita.com/nomime.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi,
Alon Bar-Lev wrote:
> 1. Why don't you put this variable at config, and allow the user to
> specify the length during configuration? I have a patch that does just
> that.
If you'd post it, it would probably get more attention :)
> 2. THE MOST IMPORTANT task is to update the documentation at
> i386/boot.txt so that it will state that boot protocol 2.02+ field
> cmd_line_ptr should not be truncated and can be up to 4K bytes.
> Also fix "The kernel command line is null-terminated string up to 255
> characters long,..." this is good for the old boot protocol, but not
> for the 2.02+ protocol.
>
> Without this fix the bootloaders (Lilo, Grub) will not fix their
> code... So that users will still will not be able to use > 256 command
> line.
syslinux >=3.09 supports 512 chars.
Greetings,
Georg
On 10/10/05, Georg Lippold <[email protected]> wrote:
> Hi,
>
> > 1. Why don't you put this variable at config, and allow the user to
> > specify the length during configuration? I have a patch that does just
> > that.
> If you'd post it, it would probably get more attention :)
I got enough attention... I just wait for documentation update... This
is the important mile-stone for this change...
> > 2. THE MOST IMPORTANT task is to update the documentation at
> > Without this fix the bootloaders (Lilo, Grub) will not fix their
> > code... So that users will still will not be able to use > 256 command
> > line.
>
> syslinux >=3.09 supports 512 chars.
Unless the documentation will be updated and it will be clear that the
boot protocol allows long command-line strings that are truncated by
the kernel at max, this task is not finished... the fact that there is
one bootloader that does that is not enough... Regardless... 512 bytes
is too small...
Best Regards,
Alon Bar-Lev.
Jesper Juhl wrote:
>
> Would it make sense to make it 1024 everywhere (and maybe move it out
> of arch specific files and just set it in one central place) ?
>
I would agree with that, *BUT* the boot protocol on each architecture
need to be consistent.
At the very least, though, i386 and x86-64 need to be changed together,
since they use the same bootstrap.
-hpa
On 10/10/05, H. Peter Anvin <[email protected]> wrote:
> Jesper Juhl wrote:
> >
> > Would it make sense to make it 1024 everywhere (and maybe move it out
> > of arch specific files and just set it in one central place) ?
> >
>
> I would agree with that, *BUT* the boot protocol on each architecture
> need to be consistent.
>
> At the very least, though, i386 and x86-64 need to be changed together,
> since they use the same bootstrap.
>
Great!
Will you update the documentation of all?
After that I can try to convince bootloaders fix their code...
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev wrote:
> On 10/10/05, H. Peter Anvin <[email protected]> wrote:
>
>>Jesper Juhl wrote:
>>
>>>Would it make sense to make it 1024 everywhere (and maybe move it out
>>>of arch specific files and just set it in one central place) ?
>>>
>>
>>I would agree with that, *BUT* the boot protocol on each architecture
>>need to be consistent.
>>
>>At the very least, though, i386 and x86-64 need to be changed together,
>>since they use the same bootstrap.
>
> Great!
> Will you update the documentation of all?
> After that I can try to convince bootloaders fix their code...
>
You have a funny way of assigning people action items.
-hpa
H. Peter Anvin wrote:
>>
>> Would it make sense to make it 1024 everywhere (and maybe move it out
>> of arch specific files and just set it in one central place) ?
>>
>
> I would agree with that, *BUT* the boot protocol on each architecture
> need to be consistent.
> At the very least, though, i386 and x86-64 need to be changed together,
> since they use the same bootstrap.
I think it will take rather long to synchronize all archs. Maybe x86 can
fix it fast (it would ease the making of LiveCD's) and then initiate a
standardization on lkml? Knoppix has its kernel patch for over a year
now and I asked gentoo to do so, too. But they said, I should ask for it
here... Until the fix is in the distributions-kernel, probably another
month will pass and it obviously needs to be fixed.
Greetings,
Georg
Georg Lippold wrote:
>
>>At the very least, though, i386 and x86-64 need to be changed together,
>>since they use the same bootstrap.
>
> I think it will take rather long to synchronize all archs. Maybe x86 can
> fix it fast (it would ease the making of LiveCD's) and then initiate a
> standardization on lkml? Knoppix has its kernel patch for over a year
> now and I asked gentoo to do so, too. But they said, I should ask for it
> here... Until the fix is in the distributions-kernel, probably another
> month will pass and it obviously needs to be fixed.
>
I would suggest updating your patch to include x86-64 and documentation,
and submit it. Other architectures will have to do this as it suits them.
-hpa
H. Peter Anvin wrote:
>
> You have a funny way of assigning people action items.
>
I am sorry... But... You are the author of this document, right?
THE LINUX/I386 BOOT PROTOCOL
----------------------------
H. Peter Anvin <[email protected]>
Last update 2002-01-01
Do you want me yo suggest the update? I will be glad!
I don't really understand (yet) how you guys working... I am
learning... So please help me understand.
Best Regards,
Alon Bar-Lev.
On Mon, 2005-10-10 at 18:23 +0200, Alon Bar-Lev wrote:
[...]
> Do you want me yo suggest the update? I will be glad!
^^^^^^^
Probably.
> I don't really understand (yet) how you guys working... I am
> learning... So please help me understand.
1) You want something changed, you propse a (tested) patch which
actually changes the code you want. And then be prepared that
2) (at least) the maintaniners of concerned
drivers/architectures/subsystems may have some seriuos problems with
the direction your patch points to (let alone coding style).
3) Then you update/improve your patch.
4) Goto 1 until the patch is accepted or you withdraw it.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
H. Peter Anvin wrote on Mon, Oct 10, 2005 at 08:49:04AM -0700:
> I would suggest updating your patch to include x86-64 and documentation,
> and submit it. Other architectures will have to do this as it suits them.
As requested.
Signed-off-by: Georg Lippold <[email protected]>
diff -ur linux~/Documentation/i386/boot.txt linux/Documentation/i386/boot.txt
--- linux~/Documentation/i386/boot.txt 2005-09-30 23:17:35.000000000 +0200
+++ linux/Documentation/i386/boot.txt 2005-10-10 18:53:11.000000000 +0200
@@ -236,7 +236,7 @@
below.
The kernel command line is a null-terminated string currently up to
-255 characters long, plus the final null. A string that is too long
+1023 characters long, plus the final null. A string that is too long
will be automatically truncated by the kernel, a boot loader may allow
a longer command line to be passed to permit future kernels to extend
this limit.
diff -ur linux~/Documentation/x86_64/boot-options.txt linux/Documentation/x86_64/boot-options.txt
--- linux~/Documentation/x86_64/boot-options.txt 2005-09-30 23:17:35.000000000 +0200
+++ linux/Documentation/x86_64/boot-options.txt 2005-10-10 18:55:26.000000000 +0200
@@ -3,6 +3,9 @@
There are many others (usually documented in driver documentation), but
only the AMD64 specific ones are listed here.
+The kernel command line (/proc/cmdline) can have up to 1023 characters
+plus the terminating \0.
+
Machine check
mce=off disable machine check
diff -ur linux~/include/asm-i386/param.h linux/include/asm-i386/param.h
--- linux~/include/asm-i386/param.h 2005-09-30 23:17:35.000000000 +0200
+++ linux/include/asm-i386/param.h 2005-10-10 18:50:43.000000000 +0200
@@ -20,6 +20,6 @@
#endif
#define MAXHOSTNAMELEN 64 /* max length of hostname */
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024
#endif
diff -ur linux~/include/asm-i386/setup.h linux/include/asm-i386/setup.h
--- linux~/include/asm-i386/setup.h 2005-09-30 23:17:35.000000000 +0200
+++ linux/include/asm-i386/setup.h 2005-10-10 18:50:09.000000000 +0200
@@ -17,7 +17,7 @@
#define MAX_NONPAE_PFN (1 << 20)
#define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024
#define OLD_CL_MAGIC_ADDR 0x90020
#define OLD_CL_MAGIC 0xA33F
diff -ur linux~/include/asm-x86_64/setup.h linux/include/asm-x86_64/setup.h
--- linux~/include/asm-x86_64/setup.h 2005-09-30 23:17:35.000000000 +0200
+++ linux/include/asm-x86_64/setup.h 2005-10-10 18:51:19.000000000 +0200
@@ -1,6 +1,6 @@
#ifndef _x8664_SETUP_H
#define _x8664_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE 1024
#endif
Georg Lippold wrote:
> H. Peter Anvin wrote on Mon, Oct 10, 2005 at 08:49:04AM -0700:
>
>>I would suggest updating your patch to include x86-64 and documentation,
Hi!
Just a few suggestions...
1. The old protocol must stay with 255 + null command
line... I suggest:
For boot protocol <2.02, the kernel command line is a
null-terminated string up to 255 characters long, plus the
final null. For boot protocol >=2.02 command line that is
referred by cmd_line_ptr is null-terminated string, the
kernel will truncate this string if it is too large to handle.
2. I suggest adding a new configuration to set the size of
command-line, so it won't be hard coded...
Add CONFIG_CMD_LINE_SIZE with default of 1024.
I've done this by init/Kconfig...
--- Kconfig 2005-10-10 20:16:14.000000000 +0200
+++ Kconfig.org 2005-10-10 20:14:13.000000000 +0200
@@ -77,13 +77,6 @@ config LOCALVERSION
object and source tree, in that order. Your
total string can
be a maximum of 64 characters.
+config CMD_LINE_SIZE
+ integer "Set maximum command line size"
+ default 1024
+ help
+ This option allows you to specify the maximum
kernel command
+ line arguments.
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
3. Set the COMMAND_LINE_SIZE to CONFIG_CMD_LINE_SIZE
I've found that not all files that includes setup.h and
param.h include config.h... So I've written:
#if defined(CONFIG_CMD_LINE_SIZE)
#define COMMAND_LINE_SIZE CONFIG_CMD_LINE_SIZE
#endif
So that it fails if you try to use COMMAND_LINE_SIZE and did
not include config.h, another alternative is to include
config.h in these include files... I don't know what the
conventions are.
Best Regards,
Alon Bar-Lev.
Hi Alon,
Alon Bar-Lev wrote:
> For boot protocol <2.02, the kernel command line is a null-terminated
> string up to 255 characters long, plus the final null. For boot protocol
>>=2.02 command line that is referred by cmd_line_ptr is null-terminated
> string, the kernel will truncate this string if it is too large to handle.
Thus, someone could use bootloaders to "patch" the kernel: If the
bootloader writes a string of arbitary length to some memory region,
then there is a fair chance that if you make the string just long
enough, the kernel image gets (partly) overwritten. It resembles a bit
"Smashing the stack for fun and profit", but this time, it's "Rewriting
the kernel to your own needs via the bootloader on x86" :)
Same thing for user defined COMMAND_LINE_SIZE. I think that a common
interface for boot loaders is required. Especially in uncontrolled multi
user environments like Universities, everything else could lead to
undesired results.
Greetings,
Georg
On 9/7/05, H. Peter Anvin <[email protected]> wrote:
> Alon Bar-Lev wrote:
> >
> > Hello Peter, I've written a reply before but got no response...
> >
> > The idea of putting arguments in initramfs is not practical, since the
> > whole idea is to have the same image of system and affecting its
> > behavior using the boot loader...
> >
>
> No, you're wrong. The boot loader can synthesize an initramfs.
>
> > I would like to push forward the idea to extend the command-line size...
> >
> > All we need for start is an updated version of the "THE LINUX/I386 BOOT
> > PROTOCOL" document that states that in the 2.02+ protocol the boot
> > loader should set cmd_line_ptr to a pointer to a null terminated string
> > without any size restriction, specifying that the kernel will read as
> > much as it can.
>
> Already pushed to Andrew. I will follow it up with a patch to extend
> the command line, at least to 512.
>
> > After I get this update, I will try to work with GRUB and LILO so that
> > they will fix their implementation. Currently they claim that they
> > understand that they should truncate the string to 256.
> >
> > After that I will provide my simple patch for setting the maximum size
> > the kernel allocates in the configuration.
> >
> > BTW: Do you know why the COMMAND_LINE_SIZE constant is located in two
> > separate include files?
>
> No, I don't. It could be because one is included from assembly code in
> the i386 architecture.
The kernel uses the setup.h COMMAND_LINE_SIZE for both assembly and C
code. COMMAND_LINE_SIZE in param.h is only for bootloader IMHO.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
Coywolf Qi Hunt wrote:
> The kernel uses the setup.h COMMAND_LINE_SIZE for both assembly and C
> code. COMMAND_LINE_SIZE in param.h is only for bootloader IMHO.
Shouldn't really be there at all, then.
-hpa
On 10/10/05, Georg Lippold <[email protected]> wrote:
>
> Thus, someone could use bootloaders to "patch" the kernel: If the
> bootloader writes a string of arbitary length to some memory region,
> then there is a fair chance that if you make the string just long
> enough, the kernel image gets (partly) overwritten. It resembles a bit
> "Smashing the stack for fun and profit", but this time, it's "Rewriting
> the kernel to your own needs via the bootloader on x86" :)
>
> Same thing for user defined COMMAND_LINE_SIZE. I think that a common
> interface for boot loaders is required. Especially in uncontrolled multi
> user environments like Universities, everything else could lead to
> undesired results.
>
But the address of cmd_line_ptr is defined to be from the end of the
setup to 0xa0000. This is well defined, since the boot loader will
load the kernel, initramfs and cmd_line_ptr to the correct place...
Nothing is overwritten... Then the kernel is up and takes as much as
it needs from cmd_line_ptr.
Best Regards,
Alon Bar-Lev
Alon Bar-Lev wrote:
> But the address of cmd_line_ptr is defined to be from the end of the
> setup to 0xa0000. This is well defined, since the boot loader will
> load the kernel, initramfs and cmd_line_ptr to the correct place...
> Nothing is overwritten... Then the kernel is up and takes as much as
> it needs from cmd_line_ptr.
OK, then: Update my patch if you want to and resubmit it. I would like
to get this through as quickly as possible.
Greetings,
Georg
Georg Lippold wrote:
> Alon Bar-Lev wrote:
>
>>But the address of cmd_line_ptr is defined to be from the end of the
>>setup to 0xa0000. This is well defined, since the boot loader will
>>load the kernel, initramfs and cmd_line_ptr to the correct place...
>>Nothing is overwritten... Then the kernel is up and takes as much as
>>it needs from cmd_line_ptr.
>
>
> OK, then: Update my patch if you want to and resubmit it. I would like
> to get this through as quickly as possible.
>
> Greetings,
>
> Georg
>
OK...
Here it goes...
I don't have git...
I hope it is enough...
diff -urNp linux-2.6.13.4.org/Documentation/i386/boot.txt
linux-2.6.13.4/Documentation/i386/boot.txt
--- linux-2.6.13.4.org/Documentation/i386/boot.txt
2005-10-10 20:54:29.000000000 +0200
+++ linux-2.6.13.4/Documentation/i386/boot.txt 2005-10-11
19:01:40.000000000 +0200
@@ -230,12 +230,13 @@ loader to communicate with the kernel.
relevant to the boot loader itself, see "special command
line options"
below.
-The kernel command line is a null-terminated string up to 255
-characters long, plus the final null.
+If the boot protocol version is 2.01 or older, the kernel
command line is
+a null-terminated string up to 255 characters long, plus
the final null.
If the boot protocol version is 2.02 or later, the address
of the
kernel command line is given by the header field
cmd_line_ptr (see
-above.)
+above.), the kernel may truncate this string if it is too long
+for handle.
If the protocol version is *not* 2.02 or higher, the kernel
command line is entered using the following protocol:
diff -urNp linux-2.6.13.4.org/include/asm-i386/param.h
linux-2.6.13.4/include/asm-i386/param.h
--- linux-2.6.13.4.org/include/asm-i386/param.h 2005-10-10
20:54:29.000000000 +0200
+++ linux-2.6.13.4/include/asm-i386/param.h 2005-10-11
19:08:42.000000000 +0200
@@ -20,6 +20,5 @@
#endif
#define MAXHOSTNAMELEN 64 /* max length of hostname */
-#define COMMAND_LINE_SIZE 256
#endif
diff -urNp linux-2.6.13.4.org/include/asm-i386/setup.h
linux-2.6.13.4/include/asm-i386/setup.h
--- linux-2.6.13.4.org/include/asm-i386/setup.h 2005-10-10
20:54:29.000000000 +0200
+++ linux-2.6.13.4/include/asm-i386/setup.h 2005-10-11
19:10:46.000000000 +0200
@@ -17,7 +17,10 @@
#define MAX_NONPAE_PFN (1 << 20)
#define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+
+#ifdef CONFIG_COMMAND_LINE_MAX_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_MAX_SIZE
+#endif
#define OLD_CL_MAGIC_ADDR 0x90020
#define OLD_CL_MAGIC 0xA33F
diff -urNp linux-2.6.13.4.org/include/asm-x86_64/setup.h
linux-2.6.13.4/include/asm-x86_64/setup.h
--- linux-2.6.13.4.org/include/asm-x86_64/setup.h 2005-10-10
20:54:29.000000000 +0200
+++ linux-2.6.13.4/include/asm-x86_64/setup.h 2005-10-11
19:21:18.000000000 +0200
@@ -1,6 +1,8 @@
#ifndef _x8664_SETUP_H
#define _x8664_SETUP_H
-#define COMMAND_LINE_SIZE 256
+#ifdef CONFIG_COMMAND_LINE_MAX_SIZE
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_MAX_SIZE
+#endif
#endif
diff -urNp linux-2.6.13.4.org/init/Kconfig
linux-2.6.13.4/init/Kconfig
--- linux-2.6.13.4.org/init/Kconfig 2005-10-10
20:54:29.000000000 +0200
+++ linux-2.6.13.4/init/Kconfig 2005-10-11
19:20:23.000000000 +0200
@@ -77,6 +77,13 @@ config LOCALVERSION
object and source tree, in that order. Your total
string can
be a maximum of 64 characters.
+config COMMAND_LINE_MAX_SIZE
+ int "Maximum kernel command-line size"
+ default 512
+ help
+ This option allows you to specify maximum kernel
command-line
+ for kernel to handle.
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
Alon Bar-Lev <[email protected]> writes:
>
> +config COMMAND_LINE_MAX_SIZE
> + int "Maximum kernel command-line size"
> + default 512
> + help
> + This option allows you to specify maximum kernel command-line
> + for kernel to handle.
I think making that a config is a really bad idea. What happens
when the user specifies a very large value. Or a very small one?
There are subtle dependencies with the boot loader, so this is
mostly a lie anyways. And it doesn't really safe enough memory to
bother with a CONFIG.
Also the last time I tried to increase this all kind of systems
with old bootloaders exploded (e.g. lilo on systems with large EDID
information - search the archives). Have these issues been resolved now?
If yes then I would suggest to just double the default.
If not it cannot be changed anyways.
-Andi
Andi Kleen wrote:
> Alon Bar-Lev <[email protected]> writes:
>
>>+config COMMAND_LINE_MAX_SIZE
>>+ int "Maximum kernel command-line size"
>>+ default 512
>>+ help
>>+ This option allows you to specify maximum kernel command-line
>>+ for kernel to handle.
>
>
> I think making that a config is a really bad idea. What happens
> when the user specifies a very large value. Or a very small one?
> There are subtle dependencies with the boot loader, so this is
> mostly a lie anyways. And it doesn't really safe enough memory to
> bother with a CONFIG.
I don't understand this dependency. The cmd_line_ptr is a
null terminated string which set by the boot loader.
The kernel reads this string until the null or
COMMAND_LINE_MAX_SIZE.
If the user specified too large buffer or too small buffer
it won't reflect the boot loader since it sets the maximum
sizeof the buffer, and the kernel truncates it.
> Also the last time I tried to increase this all kind of systems
> with old bootloaders exploded (e.g. lilo on systems with large EDID
> information - search the archives). Have these issues been resolved now?
> If yes then I would suggest to just double the default.
> If not it cannot be changed anyways.
I've looked at the sources of lilo and grub, both truncate
the command line to 256 into the old protocol and set the
cmd_line_ptr to point to the same place.
This change will no affect current implementation of the
bootloader, but will allow them to change the code to set
the cmd_line_ptr to the full command line.
I think that the maximum size should be set to 1024, but
since the kernel allocates a static buffer, users may wish
to optimize it. So I think that a configuration option is
the right place.
Best Regards,
Alon Bar-Lev.
On Tuesday 11 October 2005 21:24, Alon Bar-Lev wrote:
> I don't understand this dependency. The cmd_line_ptr is a
> null terminated string which set by the boot loader.
Yes and limited by it and the boot protocol. And changing that CONFIG
wont' change that. IMHO this config is highly misleading.
> I think that the maximum size should be set to 1024, but
> since the kernel allocates a static buffer, users may wish
> to optimize it. So I think that a configuration option is
> the right place.
It's a bad idea to have a CONFIG for every buffer. If we go down this way
this way we end up with a unconfigurable kernel at some point with
hundreds of obscure parameters. Just increase it if there is a need for it.
If you're really worried about memory consumption you can
make the big buffer __initdata and copy it to a newly allocated buffer of the
right size.
-Andi
Andi Kleen wrote:
>
> It's a bad idea to have a CONFIG for every buffer. If we go down this way
> this way we end up with a unconfigurable kernel at some point with
> hundreds of obscure parameters. Just increase it if there is a need for it.
> If you're really worried about memory consumption you can
> make the big buffer __initdata and copy it to a newly allocated buffer of the
> right size.
OK... So I think 1024 bytes should be used... Does it sound OK?
But I still think that the documentation should not specify
a fixed size, so that boot loaders will pass the full
command line to the kernel.
Best Regards,
Alon Bar-Lev.
Alon Bar-Lev wrote:
> OK... So I think 1024 bytes should be used... Does it sound OK?
So, it boils down to using my previously posted patch?
> But I still think that the documentation should not specify a fixed
> size, so that boot loaders will pass the full command line to the kernel.
In my patch, it states:
"a boot loader may allow
a longer command line to be passed to permit future kernels to extend
this limit."
(as always in Documentation/i386/boot.txt)
Greetings,
Georg