All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	Andi Kleen <ak@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Casey Schaufler <casey.schaufler@intel.com>,
	Asit Mallick <asit.k.mallick@intel.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Jon Masters <jcm@redhat.com>,
	linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [Patch v2 1/4] x86/speculation: Option to select app to app mitigation for spectre_v2
Date: Tue, 2 Oct 2018 11:23:28 +0200	[thread overview]
Message-ID: <20181002092328.GA122128@gmail.com> (raw)
In-Reply-To: <cb7314d6deb8d1c58e2ead56fef8848b642e4e5a.1537920575.git.tim.c.chen@linux.intel.com>


* Tim Chen <tim.c.chen@linux.intel.com> wrote:

> Subject: x86/speculation: Option to select app to app mitigation for spectre_v2
>

We prefer to start commit titles with verbs, not nouns, so this should be something like:

  x86/speculation: Add option to select app to app mitigation for spectre_v2

> Jiri Kosina's patch makes IBPB and STIBP available for
> general spectre v2 app to app mitigation.  IBPB will be issued for
> switching to an app that's not ptraceable by the previous
> app and STIBP will be always turned on.
> 
> However, app to app exploit is in general difficult
> due to address space layout randomization in apps and
> the need to know an app's address space layout ahead of time.
> Users may not wish to incur app to app performance
> overhead from IBPB and STIBP for general non security sensitive apps.
> 
> This patch provides a lite option for spectre_v2 app to app
> mitigation where IBPB is only issued for security sensitive
> non-dumpable app.
> 
> The strict option will keep system at high security level
> where IBPB and STIBP are used to defend all apps against
> spectre_v2 app to app attack.

s/system
 /the system

s/attack
  attacks

> +	spectre_v2_app2app=
> +			[X86] Control app to app mitigation of Spectre variant 2
> +			(indirect branch speculation) vulnerability.
> +
> +			lite   - only turn on mitigation for non-dumpable processes
> +			strict - protect against attacks for all user processes
> +			auto   - let kernel decide lite or strict mode

Perhaps add:
			lite   - only turn on mitigation for non-dumpable processes (i.e. 
				 protect daemons and other privileged processes that tend
				 to be non-dumpable)

?

> +
> +			Not specifying this option is equivalent to
> +			spectre_v2_app2app=auto.
> +
>  	spec_store_bypass_disable=
>  			[HW] Control Speculative Store Bypass (SSB) Disable mitigation
>  			(Speculative Store Bypass vulnerability)
> diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
> index fd2a8c1..c59a6c4 100644
> --- a/arch/x86/include/asm/nospec-branch.h
> +++ b/arch/x86/include/asm/nospec-branch.h
> @@ -3,6 +3,7 @@
>  #ifndef _ASM_X86_NOSPEC_BRANCH_H_
>  #define _ASM_X86_NOSPEC_BRANCH_H_
>  
> +#include <linux/static_key.h>
>  #include <asm/alternative.h>
>  #include <asm/alternative-asm.h>
>  #include <asm/cpufeatures.h>
> @@ -217,6 +218,12 @@ enum spectre_v2_mitigation {
>  	SPECTRE_V2_IBRS_ENHANCED,
>  };
>  
> +enum spectre_v2_app2app_mitigation {
> +	SPECTRE_V2_APP2APP_NONE,
> +	SPECTRE_V2_APP2APP_LITE,
> +	SPECTRE_V2_APP2APP_STRICT,
> +};
> +
>  /* The Speculative Store Bypass disable variants */
>  enum ssb_mitigation {
>  	SPEC_STORE_BYPASS_NONE,
> @@ -228,6 +235,8 @@ enum ssb_mitigation {
>  extern char __indirect_thunk_start[];
>  extern char __indirect_thunk_end[];
>  
> +DECLARE_STATIC_KEY_FALSE(spectre_v2_app_lite);
> +
>  /*
>   * On VMEXIT we must ensure that no RSB predictions learned in the guest
>   * can be followed in the host, by overwriting the RSB completely. Both
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index ee46dcb..c967012 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -133,6 +133,12 @@ enum spectre_v2_mitigation_cmd {
>  	SPECTRE_V2_CMD_RETPOLINE_AMD,
>  };
>  
> +enum spectre_v2_app2app_mitigation_cmd {
> +	SPECTRE_V2_APP2APP_CMD_AUTO,
> +	SPECTRE_V2_APP2APP_CMD_LITE,
> +	SPECTRE_V2_APP2APP_CMD_STRICT,
> +};
> +
>  static const char *spectre_v2_strings[] = {
>  	[SPECTRE_V2_NONE]			= "Vulnerable",
>  	[SPECTRE_V2_RETPOLINE_MINIMAL]		= "Vulnerable: Minimal generic ASM retpoline",
> @@ -142,12 +148,24 @@ static const char *spectre_v2_strings[] = {
>  	[SPECTRE_V2_IBRS_ENHANCED]		= "Mitigation: Enhanced IBRS",
>  };
>  
> +static const char *spectre_v2_app2app_strings[] = {
> +	[SPECTRE_V2_APP2APP_NONE]		= "App-App Vulnerable",
> +	[SPECTRE_V2_APP2APP_LITE]		= "App-App Mitigation: Protect only non-dumpable process",
> +	[SPECTRE_V2_APP2APP_STRICT]		= "App-App Mitigation: Full app to app attack protection",
> +};
> +
> +DEFINE_STATIC_KEY_FALSE(spectre_v2_app_lite);
> +EXPORT_SYMBOL(spectre_v2_app_lite);

EXPORT_SYMBOL_GPL() I suspect?

> +
>  #undef pr_fmt
>  #define pr_fmt(fmt)     "Spectre V2 : " fmt
>  
>  static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
>  	SPECTRE_V2_NONE;
>  
> +static enum spectre_v2_mitigation spectre_v2_app2app_enabled __ro_after_init =
> +	SPECTRE_V2_APP2APP_NONE;
> +
>  void
>  x86_virt_spec_ctrl(u64 guest_spec_ctrl, u64 guest_virt_spec_ctrl, bool setguest)
>  {
> @@ -275,6 +293,46 @@ static const struct {
>  	{ "auto",              SPECTRE_V2_CMD_AUTO,              false },
>  };
>  
> +static const struct {
> +	const char *option;
> +	enum spectre_v2_app2app_mitigation_cmd cmd;
> +	bool secure;
> +} app2app_mitigation_options[] = {
> +	{ "lite",	SPECTRE_V2_APP2APP_CMD_LITE,   false },
> +	{ "strict",	SPECTRE_V2_APP2APP_CMD_STRICT, false },
> +	{ "auto",	SPECTRE_V2_APP2APP_CMD_AUTO,   false },
> +};

Am I reading this right that it's not possible to configure this to 'none', i.e. to disable the 
protection altogether?


> +	 * For lite protection mode, we only protect the non-dumpable
> +	 * processes.
> +	 *
> +	 * Otherwise check if the current (previous) task has access to the memory
> +	 * of the @tsk (next) task for strict app to app protection.
> +	 * If access is denied, make sure to
>  	 * issue a IBPB to stop user->user Spectre-v2 attacks.

s/a IBPB
 /an IBPB

Thanks,

	Ingo

  reply	other threads:[~2018-10-02  9:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-26  0:43 [Patch v2 0/4] Provide options to enable spectre_v2 userspace-userspace protection Tim Chen
2018-09-26  0:43 ` [Patch v2 1/4] x86/speculation: Option to select app to app mitigation for spectre_v2 Tim Chen
2018-10-02  9:23   ` Ingo Molnar [this message]
2018-10-02 16:24     ` Tim Chen
2018-10-02 20:04   ` Thomas Gleixner
2018-09-26  0:43 ` [Patch v2 2/4] x86/speculation: Provide application property based STIBP protection Tim Chen
2018-10-02 19:10   ` Thomas Gleixner
2018-10-04 19:19     ` Tim Chen
2018-09-26  0:43 ` [Patch v2 3/4] x86/speculation: Extend per process STIBP to AMD cpus Tim Chen
2018-09-26 17:24   ` Tim Chen
2018-09-26 19:11     ` Lendacky, Thomas
2018-10-02  9:27   ` Ingo Molnar
2018-10-02 19:02   ` Thomas Gleixner
2018-09-26  0:43 ` [Patch v2 4/4] x86/speculation: Add prctl to control indirect branch speculation per process Tim Chen
2018-10-02  9:35   ` Ingo Molnar
2018-10-02 16:12     ` Tim Chen
2018-10-03  7:25       ` Ingo Molnar
2018-10-02 17:58   ` Thomas Gleixner
2018-10-05 18:12     ` Tim Chen
2018-10-05 18:46       ` Thomas Gleixner

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=20181002092328.GA122128@gmail.com \
    --to=mingo@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=arjan@linux.intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=casey.schaufler@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=jcm@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=x86@kernel.org \
    /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.