Re: grub2 not using linux cmdline as verbatim

[Jiri Jaburek]

On 06/04/2015 08:09 PM, Andrei Borzenkov wrote:
> В Thu, 04 Jun 2015 19:24:51 +0200
> Jiri Jaburek <address@hidden> пишет:
> 
>> Hello,
>> the documentation [1] for linux / linux16 mentions that
>>
>>   "The rest of the line is passed verbatim as the kernel command-line."
>>
>> which is false, I was able to cause
>>
>>   error: syntax error.
>>   error: Incorrect command.
>>   error: syntax error.
>>
>> by specifying & (ampersand character) on the command line.
>> (Yes, grub2.cfg, not the shell generation logic.)
>>
> 
> Like in "normal" shell commands receive arguments after pre-processing
> by shell (grub CLI). grub documentation explicitly says that "&" is
> metacharacter and needs to be quoted if you want to include it verbatim.

Ah, 'metacharacter' is the term I missed when searching for this, found
a rather comprehensive description under section 5.2, thanks.

> 
>> Quoting the character seems to help, but that further proves that
>> grub doesn't treat even the quotes as verbatim text.
>>
>> Since I have all this as part of a more complex infrastructure,
>> it's impossible to hand-edit every such occurrence - could you please
>> tell me which characters have special meaning (aside from newline)
>> and/or confirm that the current behavior (not treating text as
>> verbatim) is a bug?
>>
>> If it is a feature, what would be the easiest way to make grub
>> treat unknown (external) kernel cmdline as valid? Quoting the entire
>> cmdline (after kernel filename) seems to leave the quotes intact and
>> take the cmdline as verbatim, but I don't want the extra quotes to
>> be there if I need them to make grub treat the cmdline as verbatim
>> in the first place.
>>
>> TL;DR:
>>
>> - this works:
>>   linux16 /somekernel opt1 opt2 opt3
>>
>> - this triggers syntax error:
>>   linux16 /somekernel opt1 opt2&opt3
>>
>> - this works, but removes the quotes:
>>   linux16 /somekernel opt1 "opt2&opt3"
>>
> 
> Are you surprised that
> 
> echo "opt2&opt3"
> 
> outputs
> 
> opt2&opt3
> 
> without quotes?

Seeing that grub2's shell language applies to the kernel cmdline as
well, not anymore.

> 
>> - this also works, but leaves the quotes intact:
>>   linux16 /somekernel "opt1 opt2&opt3"
>>
> 
> Yes, this is a bit magical. GRUB sees space in argument and quotes it
> so kernel will correctly parse it as a single word and not split in
> multiple arguments. Think about it it as a syntactic sugar which frees
> user from using extra quotes like
> 
> linux /vmlinuz '"single argument with spaces"'

The problem happens when an external pre-parser is already in place,
sanitizing possible user input for multiple bootloaders like syslinux,
zipl (system-z), grub1, lilo, u-boot, various EFI loaders, ..., or when
the cmdline is specified by the user in a bootloader-agnostic way.

In my specific example, a user wanted to pass `&' as a kernel module
parameter value, which works just about everywhere except grub2, which
does additional parsing on the cmdline.

The point is that even if I wrote an anti-parser to grub2's parser,
escaping quotes and sequences to make it pass the cmdline 1:1 as the
user specified (this might include intentionally broken syntax for
kernel testing), I can't catch everything - for example I was unable
to make grub2 send a single `\' (backslash) character - specifying it
twice `\\' left two characters in place (instead of one), specifying
it once just made grub2 replace it with quotes.
Using variables didn't help much either.

Considering this, would you see a feature request for parser-less
handling of the kernel cmdline sane?

Maybe it could be implemented as assignment of "raw" content into
a variable and then using the variable as-is, to be more versatile.
Maybe an external file with kernel cmdline (like system-z), able to
contain even newlines or any other non-ascii bytes.

> 
> May be it should be explicitly mentioned in documentation.

While using "verbatim" is technically correct, as it - according to
the English dictionary - refers to "words" and grub2 says words are
sequences of characters separated by metacharacters, it is a bit
misleading to mention "verbatim" in the first place.

Thanks for the reply,
Jiri

> 
>> Reproducible with grub-2.02 on x86 and powerpc at least, on
>> RHEL/Fedora, but reproduced with Super Grub Disk, so it's not
>> downstream-specific.
>>
>> Thanks,
>> Jiri
>>
>>
>> [1]: http://www.gnu.org/software/grub/manual/grub.html#linux
>>