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

[Rob Landley <rob@landley.net>]

On 10/14/14 16:00, Andrew Morton 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=?

Adding kernel command line options isn't tiresome? A quick grep of
kernel-parameters.txt ballparks us at around 600 of them so far, and the
one you're proposing one would would translate to "and I really mean it".

Chopping out legacy code with an ifconfig is a step to deprecating it
and eventually removing it. Adding code to do less is bloat that will
stay there forever.

The old behavior is surprising, most people putting together systems in
the past 10 years probably aren't aware it does that unless they got bit
by it. You can't specify a series of fallback inits from the command
line, only the magic hardcoded values can provide a random mix of places
to look for "init" (including in /etc/init for some reason? Has that
_ever_ been a thing?) and then calling a different program entirely
("sh") at a hardwired absolute path because reasons.

Initramfs does not do this fallback nonsense, it has one place it looks
("/init") and rdinit= changes that without magic fallbacks to the old
one if it's not found. If you specify rdinit= it won't even look for
"/init":

        if (!ramdisk_execute_command)
                ramdisk_execute_command = "/init";

        if (sys_access((const char __user *) ramdisk_execute_command, 0)
!= 0) {
                ramdisk_execute_command = NULL;
                prepare_namespace();
        }


(I.E. if it finds the one and only rdinit command name in ramfs, it
doesn't overmount it with the root= contents. Once overmounted, any
other init programs in ramfs wouldn't matter.)

The current behavior is inconsistent and crazy, and only there for
legacy reasons. We _already_ don't do it for newer codepaths. That's why
chopping it out with kconfig (and immediately deprecating the config
option) makes more sense than adding extra code to not do it.

Rob