lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 20 Oct 2014 14:01:55 -0700
From:	Josh Triplett <>
To:	Andy Lutomirski <>
Cc:	Andrew Morton <>,
	Rob Landley <>,
	Frank Rowand <>,
	"" <>,
	Chuck Ebbert <>,
	Randy Dunlap <>,
	Shuah Khan <>
Subject: Re: [PATCH v5] init: Disable defaults if init= fails

On Mon, Oct 20, 2014 at 01:14:54PM -0700, Andy Lutomirski wrote:
> On Tue, Oct 14, 2014 at 2:00 PM, Andrew Morton
> <> wrote:
> > On Wed, 1 Oct 2014 11:13:14 -0700 Andy Lutomirski <> wrote:
> >
> >> On Wed, Oct 1, 2014 at 11:05 AM,  <> wrote:
> >> > On Tue, Sep 30, 2014 at 09:53:56PM -0700, Andy Lutomirski wrote:
> >> >> I significantly prefer default N.  Scripts that play with init= really
> >> >> don't want the fallback, and I can imagine contexts in which it could
> >> >> be a security problem.
> >> >
> >> > While I certainly would prefer the non-fallback behavior for init as
> >> > well, standard kernel practice has typically been to use "default y" for
> >> > previously built-in features that become configurable.  And I'd
> >> > certainly prefer a compile-time configuration option like this (even
> >> > with default y) over a "strictinit" kernel command-line option.
> >> >
> >>
> >> Fair enough.
> >>
> >> So: "default y" for a release or two, then switch the default?  Having
> >> default y will annoy virtme, though it's not the end of the world.
> >> Virtme is intended to work with more-or-less-normal kernels.
> >>
> >
> > Adding another Kconfig option is tiresome.  What was wrong with strictinit=?
> Now that this thread has gotten absurdly wrong, any thoughts?
> My preference order is:
> 1. The patch as is.
> 2. The patch, minus the config option (i.e. making it unconditional).
> 3. Something else.


> I would very much prefer to get *something* merged.  The current
> behavior is problematic for scripted kernel boots that don't use
> initramfs.
> I can be flexible on the something else.  One option would be to allow
> a whole list of commands in init=, but that has compatibility issues.
> Another would be adding an option like init_fallback=/bin/sh.  A third
> is the original strictinit mechanism.  I don't really like any of
> them, because they're all more complex.

I agree, particularly because they *add* more logic rather than
*removing* logic.  In this case, I think a Kconfig option makes sense,
because it controls additional behavior (the init fallback mechanism).

Plus, adding more code to control init fallback at runtime then means I
have more code to compile out to make the kernel smaller, so I'd end up
adding that Kconfig option anyway. :)

> IOW, the no-fallback behavior is easy to implement, easy to
> understand, and has extremely predictable behavior.  The fallback
> behavior is more user friendly if you consider having a chance of
> booting to something useful if you typo your init= option (but also a
> chance of booting to something actively undesirable).

Here's an alternative proposal: how about we change the default
*without* a Kconfig option, see if anyone screams, and if they do, we
add that code back in under a Kconfig option as in your current patch?

Would that make your Kconfig senses stop tingling, Andrew? :)

- Josh Triplett
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists