Re: [PATCH v5] init: Disable defaults if init= fails

[Josh Triplett <josh@joshtriplett.org>]

On Mon, Oct 20, 2014 at 01:14:54PM -0700, Andy Lutomirski wrote:
> On Tue, Oct 14, 2014 at 2:00 PM, Andrew Morton
> <akpm@linux-foundation.org> wrote:
> > On Wed, 1 Oct 2014 11:13:14 -0700 Andy Lutomirski <luto@amacapital.net> wrote:
> >
> >> On Wed, Oct 1, 2014 at 11:05 AM,  <josh@joshtriplett.org> 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.

Agreed.

> 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