2018-08-07 22:26:59

by Jim Mattson

[permalink] [raw]
Subject: [PATCH] x86/spectre: Expand test for vulnerability to empty RSB exploits

Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
conditions. On hardware, platform vulnerability can be determined
simply by checking the processor's DisplayModel/DisplayFamily
signature. However, when running in a VM, the operating system should
also query IA32_ARCH_CAPABILITIES.RSBA[bit 2], a synthetic bit that
can be set by a hypervisor to indicate that the VM might run on a
vulnerable physical processor, regardless of the
DisplayModel/DisplayFamily reported by CPUID.

Note that IA32_ARCH_CAPABILITIES.RSBA[bit 2] is always clear on
hardware, so the DisplayModel/DisplayFamily check is still required.

For all of the details, see the Intel white paper, "Retpoline: A
Branch Target Injection Mitigation" (document number 337131-001),
section 5.3: Virtual Machine CPU Identification.

Signed-off-by: Jim Mattson <[email protected]>
Reviewed-by: Peter Shier <[email protected]>
---
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/kernel/cpu/bugs.c | 14 +++++++++++++-
2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 68b2c3150de1..f37ec58c4e04 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -70,6 +70,7 @@
#define MSR_IA32_ARCH_CAPABILITIES 0x0000010a
#define ARCH_CAP_RDCL_NO (1 << 0) /* Not susceptible to Meltdown */
#define ARCH_CAP_IBRS_ALL (1 << 1) /* Enhanced IBRS support */
+#define ARCH_CAP_RSBA (1 << 2) /* Vulnerable to empty RSB */
#define ARCH_CAP_SSB_NO (1 << 4) /*
* Not susceptible to Speculative Store Bypass
* attack, so no Speculative Store Bypass
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..b6fe335746a4 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -330,6 +330,18 @@ static bool __init is_skylake_era(void)
return false;
}

+/* Check for vulnerability to exploits of empty RSB conditions */
+static bool __init is_vulnerable_to_empty_rsb(void)
+{
+ u64 ia32_cap = 0;
+
+ if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
+ rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
+
+ return (ia32_cap & ARCH_CAP_RSBA) || is_skylake_era();
+}
+
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -402,7 +414,7 @@ static void __init spectre_v2_select_mitigation(void)
* switch is required.
*/
if ((!boot_cpu_has(X86_FEATURE_PTI) &&
- !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
+ !boot_cpu_has(X86_FEATURE_SMEP)) || is_vulnerable_to_empty_rsb()) {
setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
}
--
2.18.0.597.ga71716f1ad-goog



2018-08-08 15:56:10

by Konrad Rzeszutek Wilk

[permalink] [raw]
Subject: Re: [PATCH] x86/spectre: Expand test for vulnerability to empty RSB exploits

On Tue, Aug 07, 2018 at 03:25:35PM -0700, Jim Mattson wrote:
> Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
> conditions. On hardware, platform vulnerability can be determined
> simply by checking the processor's DisplayModel/DisplayFamily
> signature. However, when running in a VM, the operating system should
> also query IA32_ARCH_CAPABILITIES.RSBA[bit 2], a synthetic bit that
> can be set by a hypervisor to indicate that the VM might run on a
> vulnerable physical processor, regardless of the
> DisplayModel/DisplayFamily reported by CPUID.
>
> Note that IA32_ARCH_CAPABILITIES.RSBA[bit 2] is always clear on
> hardware, so the DisplayModel/DisplayFamily check is still required.
>
> For all of the details, see the Intel white paper, "Retpoline: A
> Branch Target Injection Mitigation" (document number 337131-001),
> section 5.3: Virtual Machine CPU Identification.
>
> Signed-off-by: Jim Mattson <[email protected]>
> Reviewed-by: Peter Shier <[email protected]>
Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>

Thank you as it saves me from doing this :-)
> ---
> arch/x86/include/asm/msr-index.h | 1 +
> arch/x86/kernel/cpu/bugs.c | 14 +++++++++++++-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index 68b2c3150de1..f37ec58c4e04 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -70,6 +70,7 @@
> #define MSR_IA32_ARCH_CAPABILITIES 0x0000010a
> #define ARCH_CAP_RDCL_NO (1 << 0) /* Not susceptible to Meltdown */
> #define ARCH_CAP_IBRS_ALL (1 << 1) /* Enhanced IBRS support */
> +#define ARCH_CAP_RSBA (1 << 2) /* Vulnerable to empty RSB */
> #define ARCH_CAP_SSB_NO (1 << 4) /*
> * Not susceptible to Speculative Store Bypass
> * attack, so no Speculative Store Bypass
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 5c0ea39311fe..b6fe335746a4 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -330,6 +330,18 @@ static bool __init is_skylake_era(void)
> return false;
> }
>
> +/* Check for vulnerability to exploits of empty RSB conditions */
> +static bool __init is_vulnerable_to_empty_rsb(void)
> +{
> + u64 ia32_cap = 0;
> +
> + if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES))
> + rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
> +
> + return (ia32_cap & ARCH_CAP_RSBA) || is_skylake_era();
> +}
> +
> +
> static void __init spectre_v2_select_mitigation(void)
> {
> enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
> @@ -402,7 +414,7 @@ static void __init spectre_v2_select_mitigation(void)
> * switch is required.
> */
> if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> - !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> + !boot_cpu_has(X86_FEATURE_SMEP)) || is_vulnerable_to_empty_rsb()) {
> setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
> }
> --
> 2.18.0.597.ga71716f1ad-goog
>

2018-08-20 16:03:26

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [PATCH] x86/spectre: Expand test for vulnerability to empty RSB exploits

On Tue, 7 Aug 2018, Jim Mattson wrote:

> Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
> conditions. On hardware, platform vulnerability can be determined
> simply by checking the processor's DisplayModel/DisplayFamily
> signature. However, when running in a VM, the operating system should
> also query IA32_ARCH_CAPABILITIES.RSBA[bit 2], a synthetic bit that
> can be set by a hypervisor to indicate that the VM might run on a
> vulnerable physical processor, regardless of the
> DisplayModel/DisplayFamily reported by CPUID.
>
> Note that IA32_ARCH_CAPABILITIES.RSBA[bit 2] is always clear on
> hardware, so the DisplayModel/DisplayFamily check is still required.
>
> For all of the details, see the Intel white paper, "Retpoline: A
> Branch Target Injection Mitigation" (document number 337131-001),
> section 5.3: Virtual Machine CPU Identification.
>
> Signed-off-by: Jim Mattson <[email protected]>
> Reviewed-by: Peter Shier <[email protected]>

That has been superseeded by:

fdf82a7856b3 ("x86/speculation: Protect against userspace-userspace spectreRSB")

right? At least it does not apply anymore...

Thanks,

tglx

2018-08-20 16:27:21

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [PATCH] x86/spectre: Expand test for vulnerability to empty RSB exploits

On Mon, 20 Aug 2018, Jim Mattson wrote:
> On Mon, Aug 20, 2018 at 9:00 AM, Thomas Gleixner <[email protected]> wrote:
> >
> > On Tue, 7 Aug 2018, Jim Mattson wrote:
> >
> > > Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
> > > conditions. On hardware, platform vulnerability can be determined
> > > simply by checking the processor's DisplayModel/DisplayFamily
> > > signature. However, when running in a VM, the operating system should
> > > also query IA32_ARCH_CAPABILITIES.RSBA[bit 2], a synthetic bit that
> > > can be set by a hypervisor to indicate that the VM might run on a
> > > vulnerable physical processor, regardless of the
> > > DisplayModel/DisplayFamily reported by CPUID.
> > >
> > > Note that IA32_ARCH_CAPABILITIES.RSBA[bit 2] is always clear on
> > > hardware, so the DisplayModel/DisplayFamily check is still required.
> > >
> > > For all of the details, see the Intel white paper, "Retpoline: A
> > > Branch Target Injection Mitigation" (document number 337131-001),
> > > section 5.3: Virtual Machine CPU Identification.
> > >
> > > Signed-off-by: Jim Mattson <[email protected]>
> > > Reviewed-by: Peter Shier <[email protected]>
> >
> > That has been superseeded by:
> >
> > fdf82a7856b3 ("x86/speculation: Protect against userspace-userspace spectreRSB")
> >
> > right? At least it does not apply anymore...
>
> Right. It doesn't appear that Skylake CPUs get any special treatment any more.

Yeah, it's universally f*cked up by now.

Thanks,

tglx


2018-08-20 17:28:15

by Jim Mattson

[permalink] [raw]
Subject: Re: [PATCH] x86/spectre: Expand test for vulnerability to empty RSB exploits

On Mon, Aug 20, 2018 at 9:00 AM, Thomas Gleixner <[email protected]> wrote:
>
> On Tue, 7 Aug 2018, Jim Mattson wrote:
>
> > Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
> > conditions. On hardware, platform vulnerability can be determined
> > simply by checking the processor's DisplayModel/DisplayFamily
> > signature. However, when running in a VM, the operating system should
> > also query IA32_ARCH_CAPABILITIES.RSBA[bit 2], a synthetic bit that
> > can be set by a hypervisor to indicate that the VM might run on a
> > vulnerable physical processor, regardless of the
> > DisplayModel/DisplayFamily reported by CPUID.
> >
> > Note that IA32_ARCH_CAPABILITIES.RSBA[bit 2] is always clear on
> > hardware, so the DisplayModel/DisplayFamily check is still required.
> >
> > For all of the details, see the Intel white paper, "Retpoline: A
> > Branch Target Injection Mitigation" (document number 337131-001),
> > section 5.3: Virtual Machine CPU Identification.
> >
> > Signed-off-by: Jim Mattson <[email protected]>
> > Reviewed-by: Peter Shier <[email protected]>
>
> That has been superseeded by:
>
> fdf82a7856b3 ("x86/speculation: Protect against userspace-userspace spectreRSB")
>
> right? At least it does not apply anymore...

Right. It doesn't appear that Skylake CPUs get any special treatment any more.