[Top][All Lists]

[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: Mon, 8 Jun 2015 20:23:06 +0300

В 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
> '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.
> ( )
> 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

reply via email to

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