Re: grub2 not using linux cmdline as verbatim

[Andrei Borzenkov]

В 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 :)

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

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