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

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <542B7200.6030902@landley.net>
Date:	Tue, 30 Sep 2014 22:16:16 -0500
From:	Rob Landley <rob@...dley.net>
To:	frowand.list@...il.com
CC:	Andy Lutomirski <luto@...capital.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Chuck Ebbert <cebbert.lkml@...il.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Shuah Khan <shuah.kh@...sung.com>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH v5] init: Disable defaults if init= fails

On 09/30/14 20:52, Frank Rowand wrote:
> On 9/30/2014 5:58 PM, Rob Landley wrote:
>> If you're going to argue that it should "default y", that's a defensible
>> choice. But please don't argue for kernel config symbols with a negative
>> meaning or we'll start having allyesconfig_n brain damage too...
> 
> Yes, "default y" is a valid answer to my request.

Works for me.

>>> Instead of using a config option, would adding another kernel
>>> command line option, such as 'init_fail_is_fatal', work for
>>> your needs?
>>
>> That was the previous series of patches you ignored, which added code so
>> you can provide _extra_ kernel commands to tell it _not_ to do stuff.
>> The patches did not generate noticeable enthusiasm.
> 
> But there also was not a strong push back either.  Just Chuck's suggestion
> of an alternate syntax, and your suggestion of instead using a config
> option (and possibly immediately deprecating the config option).
> 
> You could as easily frame the argument that the added code was to
> tell the kernel to "_do_ stuff" (panic) instead of "_not_ do stuff".
> But that is just semantics on my part; whatever.
> 
> I thought the general trend was to try to avoid adding config options.
> The strictinit method seems fine to me.

Embedded guys care:

http://elinux.org/Linux_Tiny

http://lkml.iu.edu//hypermail/linux/kernel/1409.2/03763.html

>>> I have a feeling this has already been proposed,
>>> as the 'strictinit' option mentioned in the changes from v3
>>> below might be the same concept?
>>
>> That was it, yes.
>>
>> Having to get your kernel config right (and your kernel command line
>> right) in order for your system to boot is not really a new concept, is
>> it? You can still specify "init=/bin/sh" if you want that. (I do it all
>> the time when I need to edit a system I haven't bothered to look up the
>> root password to.)
> 
> Yes, of course I can.  So it falls back to personal preference (as I said,
> I like that some failed boots will drop into a shell without having to
> change the kernel command line).

The config option lets it do that. Default Y preserves the old behavior.

*shrug*

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/