[PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]


Extending the kernel parameters to a user determined size
on boot protocol >=2.02 for i386 and x86_64 architectures.

Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com>

---

Hello,

Current implementation allows the kernel to receive up to 
255 characters from the bootloader.

In current environment, the command-line is used in order to 
specify many values, including suspend/resume, module 
arguments, splash, initramfs and more.

255 characters are not enough anymore.

This is take 3 of this submission:

Take 1 - Patch that allows command-line size to be 
determined in menuconfig. People did not want to see a new 
config option.

Take 2 - Removed the menuconfig into a fixed 2048 size. This 
patch was rejected. This is what the 2.6.11-rc2 changelog 
has to say about the matter:

 > Revert "x86_64/i386: increase command line size" patch
 > It's a bootup dependancy, you can't just increase it
 > randomly, and it breaks booting with LILO.
 > Pointed out by Janos Farkas and Adrian Bunk.

Take 3 (current) - Back to menuconfig option, so it won't 
break LILO (Although if it is broken because of this, it 
should be fixed...).

Please consider to merge.

If any of you think that this should be applied for other
architectures, please reply.

Current architectures that have 256 limit are:
alpha, cris, i386, m64k, mips, sh, sh64, sparc, sparc64,
x86_64, xtensa

Current architectures that have 512 values are:
frv(512), h8300(512), ia64(512), m32r(512), m68knommu(512),
mips(512), powerpc(512), v850(512)

Current architectures that are OK:
arm(1024), arm26(1024), parisc(1024)

Current strange ones:
s390(896) - I guess IBM has a good reason for this constant...

Best Regards,
Alon Bar-Lev

[-- Attachment #2: linux-2.6.16-x86-command-line.diff --]
[-- Type: text/plain, Size: 4071 bytes --]

diff -urNp linux-2.6.16/arch/i386/Kconfig linux-2.6.16.new/arch/i386/Kconfig
--- linux-2.6.16/arch/i386/Kconfig	2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/arch/i386/Kconfig	2006-04-14 01:35:06.000000000 +0300
@@ -644,6 +644,14 @@ config EFI
 	anything about EFI).  However, even with this option, the resultant
 	kernel should continue to boot on existing non-EFI platforms.
 
+config COMMAND_LINE_SIZE
+	int "Maximum kernel command-line size"
+	range 256 4096
+	default 256
+	---help---
+	This enables adjusting maximum command-line size. If you are unsure
+	specify 256.
+
 config IRQBALANCE
  	bool "Enable kernel irq balancing"
 	depends on SMP && X86_IO_APIC
diff -urNp linux-2.6.16/arch/x86_64/Kconfig linux-2.6.16.new/arch/x86_64/Kconfig
--- linux-2.6.16/arch/x86_64/Kconfig	2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/arch/x86_64/Kconfig	2006-04-14 01:35:30.000000000 +0300
@@ -445,6 +445,14 @@ config PHYSICAL_START
 
 	  Don't change this unless you know what you are doing.
 
+config COMMAND_LINE_SIZE
+	int "Maximum kernel command-line size"
+	range 256 4096
+	default 256
+	---help---
+	This enables adjusting maximum command-line size. If you are unsure
+	specify 256.
+
 config SECCOMP
 	bool "Enable seccomp to safely compute untrusted bytecode"
 	depends on PROC_FS
diff -urNp linux-2.6.16/Documentation/i386/boot.txt linux-2.6.16.new/Documentation/i386/boot.txt
--- linux-2.6.16/Documentation/i386/boot.txt	2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/Documentation/i386/boot.txt	2006-04-14 01:55:47.000000000 +0300
@@ -235,11 +235,8 @@ 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 currently up to
-255 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.
+The kernel command line is a null-terminated string. A string that is too
+long will be automatically truncated by the kernel.
 
 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
@@ -260,6 +257,9 @@ command line is entered using the follow
 	covered by setup_move_size, so you may need to adjust this
 	field.
 
+       The kernel command line *must* be 256 bytes including the
+       final null.
+
 
 **** SAMPLE BOOT CONFIGURATION
 
diff -urNp linux-2.6.16/include/asm-i386/param.h linux-2.6.16.new/include/asm-i386/param.h
--- linux-2.6.16/include/asm-i386/param.h	2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/include/asm-i386/param.h	2006-04-14 02:00:45.000000000 +0300
@@ -19,6 +19,15 @@
 #endif
 
 #define MAXHOSTNAMELEN	64	/* max length of hostname */
+
+/*
+ * This COMMAND_LINE_SIZE definition was left here
+ * for compatability, its correct location is in setup.h.
+ * Boot loaders that use this parameters will continue
+ * to use 256 maximum command-line size.
+ */
+#ifndef CONFIG_COMMAND_LINE_SIZE
 #define COMMAND_LINE_SIZE 256
+#endif
 
 #endif
diff -urNp linux-2.6.16/include/asm-i386/setup.h linux-2.6.16.new/include/asm-i386/setup.h
--- linux-2.6.16/include/asm-i386/setup.h	2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/include/asm-i386/setup.h	2006-04-14 01:32:16.000000000 +0300
@@ -17,7 +17,7 @@
 #define MAX_NONPAE_PFN	(1 << 20)
 
 #define PARAM_SIZE 4096
-#define COMMAND_LINE_SIZE 256
+#define COMMAND_LINE_SIZE CONFIG_COMMAND_LINE_SIZE
 
 #define OLD_CL_MAGIC_ADDR	0x90020
 #define OLD_CL_MAGIC		0xA33F
diff -urNp linux-2.6.16/include/asm-x86_64/setup.h linux-2.6.16.new/include/asm-x86_64/setup.h
--- linux-2.6.16/include/asm-x86_64/setup.h	2006-03-20 07:53:29.000000000 +0200
+++ linux-2.6.16.new/include/asm-x86_64/setup.h	2006-04-14 01:33:27.000000000 +0300
@@ -1,6 +1,6 @@
 #ifndef _x8664_SETUP_H
 #define _x8664_SETUP_H
 
-#define COMMAND_LINE_SIZE	256
+#define COMMAND_LINE_SIZE	CONFIG_COMMAND_LINE_SIZE
 
 #endif

Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Joshua Hudson]

I've hit that limit once. Got around it by using rdev to set root
directory and ramdisk
paramiters.

What made the command line so big is that initrd was broken on that box (kernel
was too close to the size of the floppy), so I had to use load_ramdisk.

Stupid box couldn't boot from CD, so that was the source of the trouble.

Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Alon Bar-Lev wrote:
> diff -urNp linux-2.6.16/Documentation/i386/boot.txt linux-2.6.16.new/Documentation/i386/boot.txt
> --- linux-2.6.16/Documentation/i386/boot.txt	2006-03-20 07:53:29.000000000 +0200
> +++ linux-2.6.16.new/Documentation/i386/boot.txt	2006-04-14 01:55:47.000000000 +0300
> @@ -235,11 +235,8 @@ 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 currently up to
> -255 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.
> +The kernel command line is a null-terminated string. A string that is too
> +long will be automatically truncated by the kernel.
>  
>  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
> @@ -260,6 +257,9 @@ command line is entered using the follow
>  	covered by setup_move_size, so you may need to adjust this
>  	field.
>  
> +       The kernel command line *must* be 256 bytes including the
> +       final null.
> +
>  
>  **** SAMPLE BOOT CONFIGURATION
>  

This chunk is confusing at the very best.

	-hpa

Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

H. Peter Anvin wrote:
> Alon Bar-Lev wrote:
>> diff -urNp linux-2.6.16/Documentation/i386/boot.txt 
>> linux-2.6.16.new/Documentation/i386/boot.txt
>> --- linux-2.6.16/Documentation/i386/boot.txt    2006-03-20 
>> 07:53:29.000000000 +0200
>> +++ linux-2.6.16.new/Documentation/i386/boot.txt    2006-04-14 
>> 01:55:47.000000000 +0300
>> @@ -235,11 +235,8 @@ 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 currently up to
>> -255 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.
>> +The kernel command line is a null-terminated string. A string that is 
>> too
>> +long will be automatically truncated by the kernel.
>>  
>>  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
>> @@ -260,6 +257,9 @@ command line is entered using the follow
>>      covered by setup_move_size, so you may need to adjust this
>>      field.
>>  
>> +       The kernel command line *must* be 256 bytes including the
>> +       final null.
>> +
>>  
>>  **** SAMPLE BOOT CONFIGURATION
>>  
> 
> This chunk is confusing at the very best.
> 
>     -hpa
> 

Hello,

The problem is that boot loader developers did not 
understand the old statement: "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."

Most of them handed the same buffer to < 2.02 protocols and 
 >= 2.0.2 protocols. When I've opened bugs against that they 
claimed that they follow instructions since the 256 limit 
was explicitly mentioned. I've ended up in patching GRUB 
my-self to allow this.

I thought that this should be made clearer... But maybe I 
did not write it too well.

I've removed the 255+1 limitation from the boot protocol 
main description, so there will be no known limit there... 
And moved it to the <2.02 section notes.

Can you please suggest a different phrasing? Or maybe you 
think that it is not needed at all... But then I have a 
problem of making boot loader fix their code.

Best Regards,
Alon Bar-Lev.

Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Alon Bar-Lev wrote:
> 
> Hello,
> 
> The problem is that boot loader developers did not understand the old 
> statement: "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."
> 
> Most of them handed the same buffer to < 2.02 protocols and >= 2.0.2 
> protocols. When I've opened bugs against that they claimed that they 
> follow instructions since the 256 limit was explicitly mentioned. I've 
> ended up in patching GRUB my-self to allow this.
> 
> I thought that this should be made clearer... But maybe I did not write 
> it too well.
> 
> I've removed the 255+1 limitation from the boot protocol main 
> description, so there will be no known limit there... And moved it to 
> the <2.02 section notes.
> 
> Can you please suggest a different phrasing? Or maybe you think that it 
> is not needed at all... But then I have a problem of making boot loader 
> fix their code.
> 

Well, obviously, since apparently LILO doesn't properly null-terminate 
long command line.

Thinking about it a bit, the way to deal with the LILO problem is 
probably to actually *usw* the boot loader ID byte we've had in there 
since the 2.00 protocol.  In other words, if the boot loader ID is 0x1X 
where X <= current version (I don't know how LILO manages this ID) then 
truncate the command line to 255 bytes; when this is fixed in LILO then 
LILO gets to bump its boot loader ID version number.

	-hpa

Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[Alon Bar-Lev]

H. Peter Anvin wrote:
> 
> Well, obviously, since apparently LILO doesn't properly null-terminate 
> long command line.
> 
> Thinking about it a bit, the way to deal with the LILO problem is 
> probably to actually *usw* the boot loader ID byte we've had in there 
> since the 2.00 protocol.  In other words, if the boot loader ID is 0x1X 
> where X <= current version (I don't know how LILO manages this ID) then 
> truncate the command line to 255 bytes; when this is fixed in LILO then 
> LILO gets to bump its boot loader ID version number.
> 
>     -hpa

I don't understand...

If LILO worked until now, it should continue to work after 
applying this patch, since nothing was changed from its 
perspective. It will continue to provide 255 characters + 
null command line, so even if you have 1024 max 
command-line, then you will still receive truncated to 255 
chars.

What I think is that the boot.txt should be clearer... But 
if you think that this patch can be applied without making 
any change to the documentation that's will also be great! I 
will try to deal with boot loaders developers afterwards...

Best Regards,
Alon Bar-Lev.

Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

Alon Bar-Lev wrote:
> H. Peter Anvin wrote:
>>
>> Well, obviously, since apparently LILO doesn't properly null-terminate 
>> long command line.
>>
>> Thinking about it a bit, the way to deal with the LILO problem is 
>> probably to actually *usw* the boot loader ID byte we've had in there 
>> since the 2.00 protocol.  In other words, if the boot loader ID is 
>> 0x1X where X <= current version (I don't know how LILO manages this 
>> ID) then truncate the command line to 255 bytes; when this is fixed in 
>> LILO then LILO gets to bump its boot loader ID version number.
>>
>>     -hpa
> 
> I don't understand...
> 
> If LILO worked until now, it should continue to work after applying this 
> patch, since nothing was changed from its perspective. It will continue 
> to provide 255 characters + null command line, so even if you have 1024 
> max command-line, then you will still receive truncated to 255 chars.
> 

Does anyone know the actual details of the LILO breakage?  If the 
problem is that LILO doesn't null-terminate the string when it's too 
long, then we can deal with this automatically, without introducing 
compile-time options (which were already once rejected.)

If the problem is with LILO booting *old* kernels, then that's going to 
have to require some LILO changes, and probably a boot revision bump.

	-hpa

Re: [PATCH][TAKE 3] THE LINUX/I386 BOOT PROTOCOL - Breaking the 256 limit

[H. Peter Anvin]

By the way...

PLEASE stop sending out mail with:

Disposition-Notification-To: Alon Bar-Lev <alon.barlev@gmail.com>

	-hpa