Bug 744545

Summary:	dashes are not treated as underscores in early boot params
Product:	[Fedora] Fedora	Reporter:	Michal Schmidt <mschmidt>
Component:	kernel	Assignee:	Michal Schmidt <mschmidt>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	gansalmon, harald, huzaifas, itamar, jonathan, kay, kernel-maint, madhu.chinakonda, mads, maxim, mschmidt, psabata
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	738494	Environment:
Last Closed:	2011-11-02 13:18:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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