Bug 744545 - dashes are not treated as underscores in early boot params
Summary: dashes are not treated as underscores in early boot params
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Schmidt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-09 10:17 UTC by Michal Schmidt
Modified: 2011-11-02 13:18 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 738494
Environment:
Last Closed: 2011-11-02 13:18:29 UTC


Attachments (Terms of Use)

Description Michal Schmidt 2011-10-09 10:17:42 UTC
+++ This bug was initially created as a clone of Bug #738494 +++

The introduction in the first lines of /usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt gives a very strong indication that:

  Hyphens (dashes) and underscores are equivalent in parameter names, so
        log_buf_len=1M
  can also be entered as
        log-buf-len=1M

Adding the dashed version as a kernel parameter do however give 3 times "dracut Warning: Signal caught!" and a shell. There is _no_ indication what the problem is and it is impossible for mortals to debug it.

I assume this is a variation of the problem mentioned on https://bugzilla.redhat.com/show_bug.cgi?id=733674#c9

dracut-013-8.fc16

--- Additional comment from mschmidt@redhat.com on 2011-10-09 06:14:17 EDT ---

There are two bugs:

1) a kernel bug. It does not apply the dash-to-underscore conversion to early
   boot parameters. log_buf_len is an early parameter. As a consequence the
   string "log-buf-len=1M" gets passed in the environment to userspace.

2) [...]

Comment 1 Mads Kiilerich 2011-10-09 20:28:03 UTC
FWIW, I think it would be confusing if the kernel did dash-to-underscore conversion on everything before exporting to environment. IMHO dash-to-underscore should only be applied to kernel parameters as they are recognized by the kernel, not to other random boot parameters, and not when exporting to environment. Instead I would expect that it only exported values that had a valid sh variable name on left hand side. That would also avoid injecting other invalid identifiers in the environment, such as the case of "foo,bar=baz" as boot parameter.

Comment 2 Kay Sievers 2011-10-09 20:41:47 UTC
Nothing should rely on the fragile kernel environment variable export. The
kernel might suppress or mangle any parameter at any time.

Dracut should not export this to any file or tool, it should clean the
environment and force all tools to directly read /proc/cmdline. It's the
only safe option, everything else just asks for trouble, today and in
the future.

Please let us get rid of the use of the environment. All keys with '.' in
it are suppressed since ages, betting on luck here will just not work.
Dracut should clean the environment entirely, and not store it anywhere
else, so people do not run into such issues with mangled kernel strings.

Ideally the kernel would stop exporting anything, or at least we would
teach the kernel to suppress the exporting of any string that doesn't
match very simple key names '[A-Z_-]=' like TERM= HOME=.

Comment 3 Mads Kiilerich 2011-10-09 21:31:36 UTC
(In reply to comment #2)
> Nothing should rely on the fragile kernel environment variable export. The
> kernel might suppress or mangle any parameter at any time.

So bug 733674 should be reopened?

> Ideally the kernel would stop exporting anything, or at least we would
> teach the kernel to suppress the exporting of any string that doesn't
> match very simple key names '[A-Z_-]=' like TERM= HOME=.

Was it intentional that you only included upper case and that you included dash?

Comment 4 Michal Schmidt 2011-10-09 22:19:14 UTC
I proposed a patch to treat dashes and underscores as equal for the purpose of recognizing kernel parameters:
https://lkml.org/lkml/2011/10/9/86
It is needed regardless of the concerns about environment.

Comment 5 Kay Sievers 2011-10-10 02:12:29 UTC
(In reply to comment #3)
> Was it intentional that you only included upper case and that you included
> dash?

Yeah, ideally the entire export would go away, but to avoid breaking the
historic use cases like TERM= we could filter for the usual UNIX env key
format which is all uppercase key names. All kernel options and module
parameters usually contain lowercase in the key name.

(In reply to comment #4)
> I proposed a patch to treat dashes and underscores as equal for the purpose of
> recognizing kernel parameters

That looks good.

Comment 6 Josh Boyer 2011-10-24 17:59:00 UTC
Rusty asked for a number of changes and this didn't make it into the 3.1 kernel.  At the moment, F16 is looking to ship with 3.1 final.  Moving this bug to rawhide, where it will likely land first.

Comment 7 Josh Boyer 2011-11-02 13:18:29 UTC
This should now be in rawhide.


Note You need to log in before you can comment on or make changes to this bug.