All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: mingo@redhat.com, tglx@linutronix.de, bp@alien8.de,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	leit@meta.com,
	"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 12/12] x86/bugs: Add a separate config for missing mitigation
Date: Thu, 26 Oct 2023 10:09:17 -0700	[thread overview]
Message-ID: <ZTqdPc59HWBdP269@gmail.com> (raw)
In-Reply-To: <20231025162906.abnyb7xum7cpjwxy@treble>

Hello Josh,

On Wed, Oct 25, 2023 at 09:29:06AM -0700, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2023 at 11:11:58AM -0700, Breno Leitao wrote:
> > Currently, the CONFIG_SPECULATION_MITIGATIONS is halfway populated,
> > where some mitigations have entries in Kconfig, and they could be
> > modified, while others mitigations do not have Kconfig entries, and
> > could not be controlled at build time.
> > 
> > Create an entry for each CPU mitigation under
> > CONFIG_SPECULATION_MITIGATIONS. This allow users to enable or disable
> > them at compilation time.
> > 
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> We also probably need a CONFIG_MITIGATION_MELTDOWN.

Isn't Meltdown covered by the MITIGATION_PAGE_TABLE_ISOLATION Kconfig
entry? Would you mind clarifying what would be the difference between
CONFIG_MITIGATION_MELTDOWN and MITIGATION_PAGE_TABLE_ISOLATION, and why
do we want CONFIG_MITIGATION_MELTDOWN?

> > ---
> >  arch/x86/Kconfig           | 93 ++++++++++++++++++++++++++++++++++++++
> >  arch/x86/kernel/cpu/bugs.c | 39 ++++++++++------
> >  2 files changed, 117 insertions(+), 15 deletions(-)

<snip>

> > +config MITIGATION_SRBDS
> > +	bool "Mitigate Special Register Buffer Data Sampling (SRBDS) hardware bug"
> > +	depends on CPU_SUP_INTEL
> > +	default y
> > +	help
> > +	  Enable mitigation for Special Register Buffer Data Sampling (SRBDS).
> > +	  SRBDS is a hardware vulnerability that allows Microarchitectural Data
> > +	  Sampling (MDS) techniques to infer values returned from special
> > +	  register accesses. An unprivileged user can extract values returned
> > +	  from RDRAND and RDSEED executed on another core or sibling thread
> > +	  using MDS techniques.
> 
> Refer to Documentation/admin-guide/hw-vuln/special-register-buffer-data-sampling.rst

Sure, I will update this and all the other suggestions that were cut
above. Thanks!

> > +	cmd = IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V2) ?  SPECTRE_V2_CMD_AUTO : SPECTRE_V2_CMD_NONE;
> >  	if (cmdline_find_option_bool(boot_command_line, "nospectre_v2") ||
> >  	    cpu_mitigations_off())
> >  		return SPECTRE_V2_CMD_NONE;
> 
> I'm thinking CONFIG_MITIGATION_SPECTRE_V2 should also affect whether the spectre v2 user
> mitigation gets enabled.

Makes sense, would something like this be enough?

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 11ccbadd8800..cfcdbfa72a81 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -1221,8 +1221,10 @@ static __ro_after_init enum spectre_v2_mitigation_cmd spectre_v2_cmd;
 static enum spectre_v2_user_cmd __init
 spectre_v2_parse_user_cmdline(void)
 {
+       int ret, i, mode;
        char arg[20];
-       int ret, i;
+
+       mode = IS_ENABLED(CONFIG_MITIGATION_SPECTRE_V2) ? SPECTRE_V2_USER_CMD_AUTO : SPECTRE_V2_USER_CMD_NONE;

        switch (spectre_v2_cmd) {
        case SPECTRE_V2_CMD_NONE:
@@ -1236,7 +1238,7 @@ spectre_v2_parse_user_cmdline(void)
        ret = cmdline_find_option(boot_command_line, "spectre_v2_user",
                                  arg, sizeof(arg));
        if (ret < 0)
-               return SPECTRE_V2_USER_CMD_AUTO;
+               return mode;

        for (i = 0; i < ARRAY_SIZE(v2_user_options); i++) {
                if (match_option(arg, ret, v2_user_options[i].option)) {
@@ -1246,8 +1248,8 @@ spectre_v2_parse_user_cmdline(void)
                }
        }

-       pr_err("Unknown user space protection option (%s). Switching to AUTO select\n", arg);
-       return SPECTRE_V2_USER_CMD_AUTO;
+       pr_err("Unknown user space protection option (%s). Switching to default\n", arg);
+       return mode;
 }


  reply	other threads:[~2023-10-26 17:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 18:11 [PATCH v5 00/12] x86/bugs: Add a separate config for each mitigation Breno Leitao
2023-10-19 18:11 ` [PATCH v5 01/12] x86/bugs: Rename GDS_FORCE_MITIGATION to MITIGATION_GDS_FORCE Breno Leitao
2023-10-19 18:11 ` [PATCH v5 02/12] x86/bugs: Rename CPU_IBPB_ENTRY to MITIGATION_IBPB_ENTRY Breno Leitao
2023-10-19 18:11 ` [PATCH v5 03/12] x86/bugs: Rename CALL_DEPTH_TRACKING to MITIGATION_CALL_DEPTH_TRACKING Breno Leitao
2023-10-19 18:11 ` [PATCH v5 04/12] x86/bugs: Rename PAGE_TABLE_ISOLATION to MITIGATION_PAGE_TABLE_ISOLATION Breno Leitao
2023-10-19 18:11 ` [PATCH v5 05/12] x86/bugs: Rename RETPOLINE to MITIGATION_RETPOLINE Breno Leitao
2023-10-19 18:11 ` [PATCH v5 06/12] x86/bugs: Rename SLS to CONFIG_MITIGATION_SLS Breno Leitao
2023-10-19 18:11 ` [PATCH v5 07/12] x86/bugs: Rename CPU_UNRET_ENTRY to MITIGATION_UNRET_ENTRY Breno Leitao
2023-10-19 18:11 ` [PATCH v5 08/12] x86/bugs: Rename CPU_IBRS_ENTRY to MITIGATION_IBRS_ENTRY Breno Leitao
2023-10-19 18:11 ` [PATCH v5 09/12] x86/bugs: Rename CPU_SRSO to MITIGATION_SRSO Breno Leitao
2023-10-19 18:11 ` [PATCH v5 10/12] x86/bugs: Rename RETHUNK to MITIGATION_RETHUNK Breno Leitao
2023-10-19 18:11 ` [PATCH v5 11/12] x86/bugs: Create a way to disable GDS mitigation Breno Leitao
2023-10-19 18:11 ` [PATCH v5 12/12] x86/bugs: Add a separate config for missing mitigation Breno Leitao
2023-10-25 16:29   ` Josh Poimboeuf
2023-10-26 17:09     ` Breno Leitao [this message]
2023-11-09 22:43       ` Josh Poimboeuf
2023-11-21 15:55         ` Breno Leitao
2023-10-23  2:59 ` [PATCH v5 00/12] x86/bugs: Add a separate config for each mitigation Yafang Shao
2023-10-24  9:50   ` Breno Leitao

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=ZTqdPc59HWBdP269@gmail.com \
    --to=leitao@debian.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=leit@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --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.