All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	Daniel Sneddon <daniel.sneddon@linux.intel.com>,
	antonio.gomez.iglesias@linux.intel.com,
	Josh Poimboeuf <jpoimboe@kernel.org>
Subject: Re: [PATCH] x86/bugs: Switch to "auto" when "ibrs" selected on Enhanced IBRS parts
Date: Thu, 14 Jul 2022 07:59:22 -0700	[thread overview]
Message-ID: <20220714145922.vs5to67omdzv6nmp@desk> (raw)
In-Reply-To: <YtABEwRnWrJyIKTY@worktop.programming.kicks-ass.net>

On Thu, Jul 14, 2022 at 01:42:11PM +0200, Peter Zijlstra wrote:
>On Thu, Jul 14, 2022 at 08:17:26AM -0300, Thadeu Lima de Souza Cascardo wrote:
>> On Wed, Jul 13, 2022 at 10:32:37PM -0700, Pawan Gupta wrote:
>> > Currently spectre_v2=ibrs forces write to MSR_IA32_SPEC_CTRL at every
>> > entry and exit. On Enhanced IBRS parts setting MSR_IA32_SPEC_CTRL[IBRS]
>> > only once at bootup is sufficient. MSR write at every kernel entry/exit
>> > incur unnecessary penalty that can be avoided.
>> >
>> > When Enhanced IBRS feature is present, switch from "ibrs" to "auto" mode
>> > so that appropriate mitigation is selected.
>> >
>> > Fixes: 7c693f54c873 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
>> > Cc: stable@vger.kernel.org # 5.10+
>> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>> > ---
>> >  arch/x86/kernel/cpu/bugs.c | 6 ++++++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
>> > index 0dd04713434b..7d7ebfdfbeda 100644
>> > --- a/arch/x86/kernel/cpu/bugs.c
>> > +++ b/arch/x86/kernel/cpu/bugs.c
>> > @@ -1303,6 +1303,12 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
>> >  		return SPECTRE_V2_CMD_AUTO;
>> >  	}
>> >
>> > +	if (cmd == SPECTRE_V2_CMD_IBRS && boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) {
>> > +		pr_err("%s selected but CPU supports Enhanced IBRS. Switching to AUTO select\n",
>> > +		       mitigation_options[i].option);
>> > +		return SPECTRE_V2_CMD_AUTO;
>> > +	}
>> > +
>> >  	spec_v2_print_cond(mitigation_options[i].option,
>> >  			   mitigation_options[i].secure);
>> >  	return cmd;
>> >
>> > base-commit: 72a8e05d4f66b5af7854df4490e3135168694b6b
>> > --
>> > 2.35.3
>> >
>> >
>>
>> Shouldn't we just use the mitigation the user asked for if it is still
>> possible? We could add the warning advising the user that a different
>> mitigation could be used instead with less penalty, but if the user asked for
>> IBRS and that is available, it should be used.
>>
>> One of the reasons for that is testing. I know it was useful enough for me and
>> it helped me find some bugs.
>
>Yeah this; if the user asks for IBRS, we should give him IBRS. I hate
>the 'I know better, let me change that for you' mentality.
>
>If you want to do something, print a warning.

Fair enough, I will change that to a warning.

Thanks,
Pawan

  reply	other threads:[~2022-07-14 14:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-14  5:32 [PATCH] x86/bugs: Switch to "auto" when "ibrs" selected on Enhanced IBRS parts Pawan Gupta
2022-07-14 11:17 ` Thadeu Lima de Souza Cascardo
2022-07-14 11:42   ` Peter Zijlstra
2022-07-14 14:59     ` Pawan Gupta [this message]
2022-07-14 16:01     ` Josh Poimboeuf
2022-07-14 17:03       ` Peter Zijlstra
2022-07-14 17:38         ` Josh Poimboeuf
2022-07-14 18:11           ` Peter Zijlstra
2022-07-14 18:42           ` Pawan Gupta
2022-07-14 23:15 ` [PATCH v2] x86/bugs: Warn when "ibrs" mitigation is " Pawan Gupta
2022-07-15  0:11   ` Thadeu Lima de Souza Cascardo
2022-07-15  2:00     ` Pawan Gupta
2022-07-15  5:25   ` Greg KH
2022-07-15 17:21     ` Pawan Gupta

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=20220714145922.vs5to67omdzv6nmp@desk \
    --to=pawan.kumar.gupta@linux.intel.com \
    --cc=antonio.gomez.iglesias@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=cascardo@canonical.com \
    --cc=daniel.sneddon@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.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.