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
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.
Cascardo.
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.
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
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.
eIBRS CPUs don't even have legacy IBRS so I don't see how this is even possible.
On Thu, Jul 14, 2022 at 09:01:06AM -0700, Josh Poimboeuf wrote:
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.
eIBRS CPUs don't even have legacy IBRS so I don't see how this is even possible.
You can still WRMSR a lot on them. Might not make sense but it 'works'.
On Thu, Jul 14, 2022 at 07:03:32PM +0200, Peter Zijlstra wrote:
On Thu, Jul 14, 2022 at 09:01:06AM -0700, Josh Poimboeuf wrote:
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.
eIBRS CPUs don't even have legacy IBRS so I don't see how this is even possible.
You can still WRMSR a lot on them. Might not make sense but it 'works'.
Even in Intel documentation, eIBRS is often referred to as IBRS. It wouldn't be surprising for a user to consider spectre_v2=ibrs to mean "use eIBRS".
I'm pretty sure there's nobody out there that wants spectre_v2=ibrs to mean "make it slower and possibly less secure because it's being used contrary to the spec".
On Thu, Jul 14, 2022 at 10:38:14AM -0700, Josh Poimboeuf wrote:
On Thu, Jul 14, 2022 at 07:03:32PM +0200, Peter Zijlstra wrote:
On Thu, Jul 14, 2022 at 09:01:06AM -0700, Josh Poimboeuf wrote:
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.
eIBRS CPUs don't even have legacy IBRS so I don't see how this is even possible.
You can still WRMSR a lot on them. Might not make sense but it 'works'.
Even in Intel documentation, eIBRS is often referred to as IBRS. It wouldn't be surprising for a user to consider spectre_v2=ibrs to mean "use eIBRS".
I'm pretty sure there's nobody out there that wants spectre_v2=ibrs to mean "make it slower and possibly less secure because it's being used contrary to the spec".
Then make it print a big honking warning.
Most people will either use auto or off, the very few people that force an option get what they ask for, not something else.
Like said upthread, it allows testing the code-paths at the very least.
On Thu, Jul 14, 2022 at 10:38:14AM -0700, Josh Poimboeuf wrote:
On Thu, Jul 14, 2022 at 07:03:32PM +0200, Peter Zijlstra wrote:
On Thu, Jul 14, 2022 at 09:01:06AM -0700, Josh Poimboeuf wrote:
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.
eIBRS CPUs don't even have legacy IBRS so I don't see how this is even possible.
You can still WRMSR a lot on them. Might not make sense but it 'works'.
Even in Intel documentation, eIBRS is often referred to as IBRS. It wouldn't be surprising for a user to consider spectre_v2=ibrs to mean "use eIBRS".
I'm pretty sure there's nobody out there that wants spectre_v2=ibrs to mean "make it slower and possibly less secure because it's being used contrary to the spec".
Apart from testing, I don't see a reason for a user to deliberately choose =ibrs on Enhanced IBRS parts. But, I am guessing most users would just rely on "=auto" mode.
So honoring what the user asked and printing a warning may be fine. And hope they would see the warning if they unintentionally chose "=ibrs" on an eIBRS part.
Thanks, Pawan
IBRS mitigation for spectre_v2 forces write to MSR_IA32_SPEC_CTRL at every kernel entry/exit. On Enhanced IBRS parts setting MSR_IA32_SPEC_CTRL[IBRS] only once at boot is sufficient. MSR writes at every kernel entry/exit incur unnecessary performance loss.
When Enhanced IBRS feature is present, print a warning about this unnecessary performance loss.
Signed-off-by: Pawan Gupta pawan.kumar.gupta@linux.intel.com --- v1->v2: Instead of changing the mitigation, print a warning about the perf loss.
v1: https://lore.kernel.org/lkml/0456b35fb9ef957d9a9138e0913fb1a3fd445dff.165774...
arch/x86/kernel/cpu/bugs.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 0dd04713434b..1c54fad3c54b 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -975,6 +975,7 @@ static inline const char *spectre_v2_module_string(void) { return ""; } #define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n" #define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n" #define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spectre v2 BHB attacks!\n" +#define SPECTRE_V2_IBRS_PERF_MSG "WARNING: IBRS mitigation selected on Enhanced IBRS CPU, this may cause unnecessary performance loss\n"
#ifdef CONFIG_BPF_SYSCALL void unpriv_ebpf_notify(int new_state) @@ -1415,6 +1416,8 @@ static void __init spectre_v2_select_mitigation(void)
case SPECTRE_V2_IBRS: setup_force_cpu_cap(X86_FEATURE_KERNEL_IBRS); + if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) + pr_warn(SPECTRE_V2_IBRS_PERF_MSG); break;
case SPECTRE_V2_LFENCE:
base-commit: 4a57a8400075bc5287c5c877702c68aeae2a033d
On Thu, Jul 14, 2022 at 04:15:35PM -0700, Pawan Gupta wrote:
IBRS mitigation for spectre_v2 forces write to MSR_IA32_SPEC_CTRL at every kernel entry/exit. On Enhanced IBRS parts setting MSR_IA32_SPEC_CTRL[IBRS] only once at boot is sufficient. MSR writes at every kernel entry/exit incur unnecessary performance loss.
When Enhanced IBRS feature is present, print a warning about this unnecessary performance loss.
Signed-off-by: Pawan Gupta pawan.kumar.gupta@linux.intel.com
Reviewed-by: Thadeu Lima de Souza Cascardo cascardo@canonical.com
v1->v2: Instead of changing the mitigation, print a warning about the perf loss.
v1: https://lore.kernel.org/lkml/0456b35fb9ef957d9a9138e0913fb1a3fd445dff.165774...
arch/x86/kernel/cpu/bugs.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 0dd04713434b..1c54fad3c54b 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -975,6 +975,7 @@ static inline const char *spectre_v2_module_string(void) { return ""; } #define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n" #define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n" #define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spectre v2 BHB attacks!\n" +#define SPECTRE_V2_IBRS_PERF_MSG "WARNING: IBRS mitigation selected on Enhanced IBRS CPU, this may cause unnecessary performance loss\n" #ifdef CONFIG_BPF_SYSCALL void unpriv_ebpf_notify(int new_state) @@ -1415,6 +1416,8 @@ static void __init spectre_v2_select_mitigation(void) case SPECTRE_V2_IBRS: setup_force_cpu_cap(X86_FEATURE_KERNEL_IBRS);
if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED))pr_warn(SPECTRE_V2_IBRS_PERF_MSG);case SPECTRE_V2_LFENCE:
base-commit: 4a57a8400075bc5287c5c877702c68aeae2a033d
2.35.3
On Thu, Jul 14, 2022 at 09:11:18PM -0300, Thadeu Lima de Souza Cascardo wrote:
On Thu, Jul 14, 2022 at 04:15:35PM -0700, Pawan Gupta wrote:
IBRS mitigation for spectre_v2 forces write to MSR_IA32_SPEC_CTRL at every kernel entry/exit. On Enhanced IBRS parts setting MSR_IA32_SPEC_CTRL[IBRS] only once at boot is sufficient. MSR writes at every kernel entry/exit incur unnecessary performance loss.
When Enhanced IBRS feature is present, print a warning about this unnecessary performance loss.
Signed-off-by: Pawan Gupta pawan.kumar.gupta@linux.intel.com
Reviewed-by: Thadeu Lima de Souza Cascardo cascardo@canonical.com
Thanks for the review.
Pawan
On Thu, Jul 14, 2022 at 04:15:35PM -0700, Pawan Gupta wrote:
IBRS mitigation for spectre_v2 forces write to MSR_IA32_SPEC_CTRL at every kernel entry/exit. On Enhanced IBRS parts setting MSR_IA32_SPEC_CTRL[IBRS] only once at boot is sufficient. MSR writes at every kernel entry/exit incur unnecessary performance loss.
When Enhanced IBRS feature is present, print a warning about this unnecessary performance loss.
Signed-off-by: Pawan Gupta pawan.kumar.gupta@linux.intel.com
v1->v2: Instead of changing the mitigation, print a warning about the perf loss.
v1: https://lore.kernel.org/lkml/0456b35fb9ef957d9a9138e0913fb1a3fd445dff.165774...
arch/x86/kernel/cpu/bugs.c | 3 +++ 1 file changed, 3 insertions(+)
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: eb23b5ef9131e6d65011de349a4d25ef1b3d4314 Gitweb: https://git.kernel.org/tip/eb23b5ef9131e6d65011de349a4d25ef1b3d4314 Author: Pawan Gupta pawan.kumar.gupta@linux.intel.com AuthorDate: Thu, 14 Jul 2022 16:15:35 -07:00 Committer: Peter Zijlstra peterz@infradead.org CommitterDate: Wed, 20 Jul 2022 19:24:53 +02:00
x86/bugs: Warn when "ibrs" mitigation is selected on Enhanced IBRS parts
IBRS mitigation for spectre_v2 forces write to MSR_IA32_SPEC_CTRL at every kernel entry/exit. On Enhanced IBRS parts setting MSR_IA32_SPEC_CTRL[IBRS] only once at boot is sufficient. MSR writes at every kernel entry/exit incur unnecessary performance loss.
When Enhanced IBRS feature is present, print a warning about this unnecessary performance loss.
Signed-off-by: Pawan Gupta pawan.kumar.gupta@linux.intel.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Reviewed-by: Thadeu Lima de Souza Cascardo cascardo@canonical.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/2a5eaf54583c2bfe0edc4fea64006656256cca17.165781485... --- arch/x86/kernel/cpu/bugs.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index 78c9082..6454bc7 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -975,6 +975,7 @@ static inline const char *spectre_v2_module_string(void) { return ""; } #define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n" #define SPECTRE_V2_EIBRS_EBPF_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS on, data leaks possible via Spectre v2 BHB attacks!\n" #define SPECTRE_V2_EIBRS_LFENCE_EBPF_SMT_MSG "WARNING: Unprivileged eBPF is enabled with eIBRS+LFENCE mitigation and SMT, data leaks possible via Spectre v2 BHB attacks!\n" +#define SPECTRE_V2_IBRS_PERF_MSG "WARNING: IBRS mitigation selected on Enhanced IBRS CPU, this may cause unnecessary performance loss\n"
#ifdef CONFIG_BPF_SYSCALL void unpriv_ebpf_notify(int new_state) @@ -1415,6 +1416,8 @@ static void __init spectre_v2_select_mitigation(void)
case SPECTRE_V2_IBRS: setup_force_cpu_cap(X86_FEATURE_KERNEL_IBRS); + if (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED)) + pr_warn(SPECTRE_V2_IBRS_PERF_MSG); break;
case SPECTRE_V2_LFENCE:
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Josh Poimboeuf -
Pawan Gupta -
Peter Zijlstra -
Thadeu Lima de Souza Cascardo -
tip-bot2 for Pawan Gupta