On 06/04/2015 08:09 PM, Andrei Borzenkov wrote: > В Thu, 04 Jun 2015 19:24:51 +0200 > Jiri Jaburek <[email protected]> пишет: > >> 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 >> _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
