Re: grub2 not using linux cmdline as verbatim

[Jiri Jaburek]

On 06/08/2015 07:23 PM, Andrei Borzenkov wrote:
> В Mon, 08 Jun 2015 17:31:16 +0200
> Jiri Jaburek <address@hidden> пишет:
> 
>>
>> Which is what I'm trying to do - I didn't know grub2 does shell
>> processing before recognizing keywords. It may be obvious to you,
>> but it wasn't for me and I'm thankful for your help so far.
>>
> 
> Any improvement to GRUB documentation is welcomed. If it takes form of
> patches it is excellent :)

I'll try to make something up in docs/grub.texi and send a small patch,
although given the response further below, I'm not sure I'm qualified
enough to write grub2 documentation.

> 
>> For example (in bash):
>>
>> $ sed -e "s@'@'\\\\''@g" -e "s/\\(.*\\)/'\\1'/" <<'EOF'
>> a'b"c d{](address@hidden
>> EOF
>> 'a'\''b"c d{](address@hidden'
>>
>> When passed to grub as the kernel cmdline, it gets transformed to:
>>
>>   "a\'b\"c d{](address@hidden"
>>
>> (instead of the original)
>>
>>   a'b"c d{](address@hidden
>>
> 
> Yes; that's overquoting I mentioned. It is certainly needs fixing.

I was exploring grub-core/script/yylex.l a bit, but didn't spot
anything obvious - then again, if it was obvious, it wouldn't be there
in the first place.

> 
>> Doing a side step with variables works around the double quotes, but
>> not around the backslashes:
>>
>>   set testvar='a'\''b"c d{](address@hidden'
>>   linux16 /some/image $testvar
>>
>> results in:
>>
>>   a\'b\"c d{](address@hidden
>>
>> Just pointing out that it's not an easy problem to solve with a simple
>> sed.
>>
> 
> Yes; in second example first result of $testvar substitution is
> split into individual words on spaces, so grub skips quoting to preserve
> them. Using
> 
> linux16 /some/image "$testvar"
> 
> will have the same result.
> 
> You again forget basic rules for grub shell input parsing.

My goal was not to have the string quoted, but exactly have it split
into words (like without the single quotes) only with special chars
having no special meaning (like with the single quotes).
Using the variable therefore serves as kind of an "eval" function.

The difference between bash and this example is that in bash, passing

  'some text'

as an argument always produces

  some text

(inside a variable / as a cmdline argument), not

  "some text"

like the grub shell does.

I'm not sure if the shell code itself does the quoting or if the
linux/linux16 lines have some additional processing, but using the
variable seems to trick the logic into thinking that only one word
was passed and avoid the quoting.

I understand that the logic is simply trying to do what the user
*probably* wants, it just gets in the way when the user wants something
different.

> 
>>
>> My use case is a system for managing a pool of machines (hardware) and
>> installing OSes on them based on user requests.
>> ( https://beaker-project.org/ )
>>
>> Here, the user can select a kernel+initrd combination and optionally
>> specify additional kernel cmdline arguments via some UI and the system
>> allocates a machine from the pool and starts the kernel+initrd via PXE.
>> This is done transparently for any HW architecture / loader from the
>> POV of the user.
>>
>> The kernel cmdline may include anything from module-specific options
>> to initrd-specific or init(1)-specific options such as IP addresses
>> or hostnames for root= on NFS, URL of an auto-installation script
>> ("kickstart" for fedora/rhel/centos, "preseed" for debian, ...), etc.
>>
>> In general, the system needs to be robust to whatever the user passes
>> on the cmdline, preferably with just a simple character-based filter
>> (printable ascii chars). The system doesn't care what happens beyond
>> the bootloader - if the kernel crashes as a result of the user passing
>> malicious arguments, that's fine.
>> The problem here is that it happens in the loader and thus automatically
>> marks the machine (HW) as "broken".
>>
> 
> I think this becomes more in place on grub-devel. What about describing
> your issue there?

Sure, although I'm not sure whether it belongs in there. Aren't bugs
supposed to go to http://savannah.gnu.org/bugs/?group=grub ?

>  
>>>
>>>> Considering this, would you see a feature request for parser-less
>>>> handling of the kernel cmdline sane?
>>>>
>>>
>>> If you mean that GRUB shell should somehow foresee that input is
>>> intended as kernel command line - that is simply not possible. If you
>>> mean fixing overquoting of kernel arguments before they are passed to
>>> kernel - sure, it is not feature request, it is bug fix.
>>
>> My use case is simply passing anything from ASCII 0x20 to 0x7e
>> (inclusive), possibly also 0x09 ('\t'), to the kernel command line,
>> as-is. I don't particularly care how that is done, I was just trying to
>> come up with something that would be "clean" and useful to others.
>>
> 
> Note that in case of Linux kernel it is simply impossible to pass lone
> `"' to kernel - it will slurp up all remaining characters as a single
> argument.

Indeed, linux/kernel/params.c is quite simple, but that's not exactly
my concern.

> 

Thanks,
Jiri