Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 22 Jun 2020 13:32:21 +0100
From:   Qais Yousef <qais.yousef@arm.com>
To:     Pranith Kumar <bobby.prani@gmail.com>
Cc:     James Morris <jmorris@namei.org>,
        "Serge E. Hallyn" <serge@hallyn.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Tyler Hicks <tyhicks@canonical.com>,
        open list <linux-kernel@vger.kernel.org>,
        "open list:SECURITY SUBSYSTEM" 
        <linux-security-module@vger.kernel.org>
Subject: Re: [RFC PATCH] security: Add a config option to disable security
 mitigations
Message-ID: <20200622123220.5qdykbd3rtjfsjkq@e107158-lin.cambridge.arm.com>
References: <20200618010755.4179-1-bobby.prani@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200618010755.4179-1-bobby.prani@gmail.com>
User-Agent: NeoMutt/20171215
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 06/17/20 18:07, Pranith Kumar wrote:
> Instead of having to pass 'mitigations=off' on the kernel command line,
> add a config option that has a similar effect.
> 
> Adding this makes it easier to disable mitigations in scenarios where
> you cannot modify the command line or are unable to pass a command line
> while booting.

Better wait to hear from others too, but I think if you want a config, then it
better support all possible variations of the option too, not just the 'off'
one.

> 
> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com>
> ---
>  kernel/cpu.c     | 2 +-
>  security/Kconfig | 8 ++++++++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 6ff2578ecf17..584eb39585d6 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -2542,7 +2542,7 @@ early_param("mitigations", mitigations_parse_cmdline);
>  /* mitigations=off */
>  bool cpu_mitigations_off(void)
>  {
> -	return cpu_mitigations == CPU_MITIGATIONS_OFF;
> +	return cpu_mitigations == CPU_MITIGATIONS_OFF || IS_ENABLED(CONFIG_DISABLE_MITIGATIONS);
>  }

So if cmdline asked for this to be auto, but the config is compiled with off
then the config always wins according to this.

This conflict makes me think this is probably going to be a bad idea because
2 points of control would create a confusion of which one should be honored.

You can set the cmdline in the config too, have you tried this?

On arm64, I can add additional cmdline paramter in the config

	Boot options --> Default kernel command string

On x86 I found this too

	Processor type and features --> Built-in kernel command line

Beside that, you can always use kexec to boot a new kernel with extra cmdline
option

The command I used in the past (from memory, so worth double checking)

	kexec --command-line "$(cat /proc/cmdline) migrations=off" -f Image

>  EXPORT_SYMBOL_GPL(cpu_mitigations_off);
>  
> diff --git a/security/Kconfig b/security/Kconfig
> index cd3cc7da3a55..90b8e9c89a6d 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -65,6 +65,14 @@ config PAGE_TABLE_ISOLATION
>  
>  	  See Documentation/x86/pti.rst for more details.
>  
> +config DISABLE_MITIGATIONS
> +	bool "Disable kernel security mitigations"
> +	default n

No need for default n in general as it is the default anyway :)

HTH.

Thanks

--
Qais Yousef