From: Chuck Ebbert <cebbert.lkml@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
Randy Dunlap <rdunlap@infradead.org>,
Shuah Khan <shuah.kh@samsung.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH v3] init: Add strictinit to disable init= fallbacks
Date: Fri, 26 Sep 2014 14:23:15 -0500 [thread overview]
Message-ID: <20140926142315.49215fc5@as> (raw)
In-Reply-To: <138a894f22366da4173c8a4f2bfb0e670c66dbec.1411758752.git.luto@amacapital.net>
On Fri, 26 Sep 2014 12:13:57 -0700
Andy Lutomirski <luto@amacapital.net> wrote:
> If a user puts init=/whatever on the command line and /whatever
> can't be run, then the kernel will try a few default options before
> giving up. If init=/whatever came from a bootloader prompt, then
> this probably makes sense. On the other hand, if it comes from a
> script (e.g. a tool like virtme or perhaps a future kselftest
> script), then the fallbacks are likely to exist, but they'll do the
> wrong thing. For example, they might unexpectedly invoke systemd.
>
> This adds a new option called strictinit. If init= and strictinit
> are both set, and the init= binary is not executable, then the
> kernel will panic immediately. If strictinit is set but init= is
> not set, then strictinit will have no effect, because the only real
> alternative would be to panic regardless of the contents of the root
> fs.
>
> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
> ---
> Documentation/kernel-parameters.txt | 8 ++++++++
> init/main.c | 16 ++++++++++++++--
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 10d51c2f10d7..1576273edce6 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3236,6 +3236,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> stifb= [HW]
> Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]]
>
> + strictinit [KNL,BOOT]
> + Normally, if the kernel can't find the init binary
> + specified by rdinit= and/or init=, then it will
> + try several fallbacks. If strictinit is set
> + and the value specified by init= does not work,
> + then the kernel will panic instead.
> + This option makes no sense if init= is not specified.
> +
> sunrpc.min_resvport=
> sunrpc.max_resvport=
> [NFS,SUNRPC]
> diff --git a/init/main.c b/init/main.c
> index bb1aed928f21..2ae0f2776155 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -131,6 +131,7 @@ static char *initcall_command_line;
>
> static char *execute_command;
> static char *ramdisk_execute_command;
> +static bool strictinit;
>
> /*
> * Used to generate warnings if static_key manipulation functions are used
> @@ -347,6 +348,13 @@ static int __init rdinit_setup(char *str)
> }
> __setup("rdinit=", rdinit_setup);
>
> +static int __init strictinit_setup(char *str)
> +{
> + strictinit = true;
> + return 1;
> +}
> +__setup("strictinit", strictinit_setup);
> +
> #ifndef CONFIG_SMP
> static const unsigned int setup_max_cpus = NR_CPUS;
> #ifdef CONFIG_X86_LOCAL_APIC
> @@ -960,8 +968,12 @@ static int __ref kernel_init(void *unused)
> ret = run_init_process(execute_command);
> if (!ret)
> return 0;
> - pr_err("Failed to execute %s (error %d). Attempting defaults...\n",
> - execute_command, ret);
> + if (strictinit)
> + panic("Requested init %s failed (error %d) and strictinit was set.",
> + execute_command, ret);
> + else
> + pr_err("Failed to execute %s (error %d). Attempting defaults...\n",
> + execute_command, ret);
> }
> if (!try_to_run_init_process("/sbin/init") ||
> !try_to_run_init_process("/etc/init") ||
Can't you just make it use "init=foo,strict" instead?
next prev parent reply other threads:[~2014-09-26 19:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-26 19:13 [PATCH v3] init: Add strictinit to disable init= fallbacks Andy Lutomirski
2014-09-26 19:23 ` Chuck Ebbert [this message]
2014-09-26 19:30 ` Rob Landley
2014-09-26 19:32 ` Andy Lutomirski
2014-09-26 19:31 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140926142315.49215fc5@as \
--to=cebbert.lkml@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=rdunlap@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=shuah.kh@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.