help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grub2 not using linux cmdline as verbatim


From: Andrei Borzenkov
Subject: Re: grub2 not using linux cmdline as verbatim
Date: Fri, 12 Jun 2015 18:34:28 +0300

В Fri, 12 Jun 2015 16:58:29 +0200
Jiri Jaburek <address@hidden> пишет:

> 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.
> 

We all had to start somewhere.

...
> > 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.
> 

grub-core/lib/cmdline.c

...
> 
> 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.
>

The GRUB command "linux" gets exactly one word with content

some text

But GRUB tries to pass them to linux kernel is such way that *linux
kernel* will *also* interpret them as single word and no ttwo separate
arguments "some" and "text".

> 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.
>

This is exactly opposite. Using unquoted variable makes GRUB see *two*
words; and because each word does not need quoting (no spaces), GRUB
does not quote them.
 
> 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.
>

OK, let's start from the beginning.

We are not speaking about arbitrary strings here. We are speaking about
Linux kernel command line. Let's make it clear from the start.

Kernel does not get array of arguments as happens in Unix user level
programs. Kernel gets single string that it has to parse to extract
individual arguments and their values. That means this single string
*must* include some delimiters to separate individual arguments as
well as some way to quote these delimiters so they can be used as
part of argument (values).

So Linux kernel is using white spaces as delimiters between individual
arguments and quotes to escape white spaces inside of argument.

Now back to grub. First GRUB script is parsed. At this point we have
standard shell grammar without any special knowledge. It means that
command

linux /foo/bar arg1 arg2="parm1 parm2" arg3

Will be parsed as *five* words

linux
/foo/bar
arg1
arg2=parm1 parm2
arg3

First word is command, subsequent words are arguments to this
command. Now GRUB command linux sees 4 arguments. It assumes that user
intends each argument to also be interpreted as single argument by
Linux kernel and *not* be split into multiple arguments. So it checks
each argument whether it includes spaces and if yes, it quotes them
*for Linux kernel*. Then it concatenates them separating by space.
Thus kernel sees the following - single - command line

arg1 "arg2=parm1 parm2" arg3

Which actually does the right thing. It allows user to write GRUB
command using the same semantic as kernel would see.

Does it finally make it clear?

...
> > 
> > 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 ?
> 

Sure, you can open bug report for overquoting (e.g. inability to pass
literal '\'), but problem is more general than that, and grub-devel has
better chances for reviewing and commenting.

> >>
> >> 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.
> >>

it is *NOT* use case - use case would be explanation why you need it.

> > 
> > 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.
> 

Sure, but then it is not GRUB concern that you cannot pass garbage. You
still need to provide good arguments why you must pass garbage.

That said, I suspect fixing overquoting would be enough to solve your
problem.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]