[PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Jiri Kosina]

From: Jiri Kosina <jkosina@suse.cz>

The article "Spectre Returns! Speculation Attacks using the Return Stack
Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
making use solely of the RSB contents even on CPUs that don't fallback to
BTB on RSB underflow (Skylake+).

Mitigate userspace-userspace attacks by always unconditionally filling RSB on
context switch when generic spectrev2 mitigation has been enabled.

[1] https://arxiv.org/pdf/1807.07940.pdf

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---

Note: this doesn't address the potential 'userspace-kernelspace' (maked as no.
4 in the article) attack variant. Mitigating that would require either filling
RSB on every kernel entry (as one of the very early Tim Chen's patches did as
part of spectrev2 mitigation proposal), or somehow (persumably throuhg objtool
or runtime ftrace-based counting) control the unmatched returns in the kernel;
and it's not yet clear whether this attack is practical at all in the first
place.

 arch/x86/kernel/cpu/bugs.c | 38 +++++++-------------------------------
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..5ae0c12390cd 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
 	return cmd;
 }
 
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
-	    boot_cpu_data.x86 == 6) {
-		switch (boot_cpu_data.x86_model) {
-		case INTEL_FAM6_SKYLAKE_MOBILE:
-		case INTEL_FAM6_SKYLAKE_DESKTOP:
-		case INTEL_FAM6_SKYLAKE_X:
-		case INTEL_FAM6_KABYLAKE_MOBILE:
-		case INTEL_FAM6_KABYLAKE_DESKTOP:
-			return true;
-		}
-	}
-	return false;
-}
-
 static void __init spectre_v2_select_mitigation(void)
 {
 	enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
 	pr_info("%s\n", spectre_v2_strings[mode]);
 
 	/*
-	 * If neither SMEP nor PTI are available, there is a risk of
-	 * hitting userspace addresses in the RSB after a context switch
-	 * from a shallow call stack to a deeper one. To prevent this fill
-	 * the entire RSB, even when using IBRS.
+	 * If spectre v2 protection has been enabled, unconditionally fill
+	 * RSB during a context switch; this protects against two independent
+	 * issues:
 	 *
-	 * Skylake era CPUs have a separate issue with *underflow* of the
-	 * RSB, when they will predict 'ret' targets from the generic BTB.
-	 * The proper mitigation for this is IBRS. If IBRS is not supported
-	 * or deactivated in favour of retpolines the RSB fill on context
-	 * switch is required.
+	 *	- RSB underflow (and switch to BTB) on Skylake+
+	 *	- sepctreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
 	 */
-	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
-		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
-		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
-	}
+	setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+	pr_info("Spectre v2 / spectreRSB mitigation: Filling RSB on context switch\n");
 
 	/* Initialize Indirect Branch Prediction Barrier if supported */
 	if (boot_cpu_has(X86_FEATURE_IBPB)) {
-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Josh Poimboeuf]

On Tue, Jul 24, 2018 at 09:53:30PM +0200, Jiri Kosina wrote:
> From: Jiri Kosina <jkosina@suse.cz>
> 
> The article "Spectre Returns! Speculation Attacks using the Return Stack
> Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
> making use solely of the RSB contents even on CPUs that don't fallback to
> BTB on RSB underflow (Skylake+).
> 
> Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> context switch when generic spectrev2 mitigation has been enabled.
> 
> [1] https://arxiv.org/pdf/1807.07940.pdf
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>

While I generally agree with this patch, isn't it odd that we would do
RSB filling on every context switch, but almost never do IBPB?

> +	 *	- RSB underflow (and switch to BTB) on Skylake+
> +	 *	- sepctreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs

"SpectreRSB"

>  	 */
> -	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> -	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> -		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> -		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
> -	}
> +	setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> +	pr_info("Spectre v2 / spectreRSB mitigation: Filling RSB on context switch\n");

"SpectreRSB" (capitalized)

-- 
Josh

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Jiri Kosina]

On Wed, 25 Jul 2018, Josh Poimboeuf wrote:

> > The article "Spectre Returns! Speculation Attacks using the Return Stack
> > Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
> > making use solely of the RSB contents even on CPUs that don't fallback to
> > BTB on RSB underflow (Skylake+).
> > 
> > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > context switch when generic spectrev2 mitigation has been enabled.
> > 
> > [1] https://arxiv.org/pdf/1807.07940.pdf
> > 
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> 
> While I generally agree with this patch, isn't it odd that we would do
> RSB filling on every context switch, but almost never do IBPB?

Yeah, I have actually been wondering exactly the same, but that's what we 
have been doing so far on SKL+, so I didn't really want to mix this aspect 
in.

I actually believe that in the name of consistency we should've been doing 
the RSB fills under the same conditions we're issuing IBPB even on SKL+; I 
can resend a patch that re-adjusts that, if that's the consensus.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Josh Poimboeuf]

On Wed, Jul 25, 2018 at 03:50:44PM +0200, Jiri Kosina wrote:
> On Wed, 25 Jul 2018, Josh Poimboeuf wrote:
> 
> > > The article "Spectre Returns! Speculation Attacks using the Return Stack
> > > Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
> > > making use solely of the RSB contents even on CPUs that don't fallback to
> > > BTB on RSB underflow (Skylake+).
> > > 
> > > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > > context switch when generic spectrev2 mitigation has been enabled.
> > > 
> > > [1] https://arxiv.org/pdf/1807.07940.pdf
> > > 
> > > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> > 
> > While I generally agree with this patch, isn't it odd that we would do
> > RSB filling on every context switch, but almost never do IBPB?
> 
> Yeah, I have actually been wondering exactly the same, but that's what we 
> have been doing so far on SKL+, so I didn't really want to mix this aspect 
> in.
> 
> I actually believe that in the name of consistency we should've been doing 
> the RSB fills under the same conditions we're issuing IBPB even on SKL+; I 
> can resend a patch that re-adjusts that, if that's the consensus.

True, in theory it might make more sense to only fill RSB when doing an
IBPB.  But given the current state of almost never doing IBPB, that
would be pointless.  RSB is cheap enough that we should just do it
unconditionally on context switch.

BTW, I've heard that IBPB actually flushes RSB, though I haven't seen
that officially documented anywhere.  Not that it matters given the
current IBPB code.

BTW^2, there was some discussion a few months back about offloading the
"when to IBPB" decision to security modules, though I don't think I've
ever seen official patches for that.

All that said, this patch is fine until if/when the IBPB strategy gets
figured out.  RSB filling is cheap.

Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>

-- 
Josh

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Linus Torvalds]

On Tue, Jul 24, 2018 at 12:53 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> context switch when generic spectrev2 mitigation has been enabled.

Shouldn't this also do something like

     x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP;

if we have HT enabled?

              Linus

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Jiri Kosina]

On Wed, 25 Jul 2018, Linus Torvalds wrote:

> > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > context switch when generic spectrev2 mitigation has been enabled.
> 
> Shouldn't this also do something like
> 
>      x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP;
> 
> if we have HT enabled?

So IIUC your comment is not really tightly related to spectreRSB, is it?

If you're making a more general remark about things that we'd also have to 
do in order to improve userspace-userspace spectrev2 prevention, then I 
agree.

It probably wouldn't be as simple as adding it to x86_spec_ctrl_base I 
think though, as the VM switching also has to save/restore it properly 
(the same way we handle SSBD). So I'd rather handle this separately, as it 
really is in principle a completely different protection.

STIBP is plugging much smaller hole than spectreRSB (as the bigger part is 
already plugged by IBPB), so I'd rather have that one in first, and look 
at improving STIBP later if noone beats me to it.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Josh Poimboeuf]

On Thu, Jul 26, 2018 at 01:11:01AM +0200, Jiri Kosina wrote:
> On Wed, 25 Jul 2018, Linus Torvalds wrote:
> 
> > > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > > context switch when generic spectrev2 mitigation has been enabled.
> > 
> > Shouldn't this also do something like
> > 
> >      x86_spec_ctrl_base |= x86_spec_ctrl_mask & SPEC_CTRL_STIBP;
> > 
> > if we have HT enabled?
> 
> So IIUC your comment is not really tightly related to spectreRSB, is it?
> 
> If you're making a more general remark about things that we'd also have to 
> do in order to improve userspace-userspace spectrev2 prevention, then I 
> agree.
> 
> It probably wouldn't be as simple as adding it to x86_spec_ctrl_base I 
> think though, as the VM switching also has to save/restore it properly 
> (the same way we handle SSBD). So I'd rather handle this separately, as it 
> really is in principle a completely different protection.
> 
> STIBP is plugging much smaller hole than spectreRSB (as the bigger part is 
> already plugged by IBPB)

Just to clarify, the IBPB hole is *not* plugged for context switches.
It's only enabled for non-dumpable processes (which are basically
non-existent in practice).

> so I'd rather have that one in first, and look at improving STIBP
> later if noone beats me to it.

It would be interesting to see performance measurements for STIBP, but
based on what we've seen with IBRS in user space, I'd guess that it's
not pretty.

-- 
Josh

[PATCH v2] x86/bugs: protect against userspace-userspace spectreRSB

[Jiri Kosina]

From: Jiri Kosina <jkosina@suse.cz>

The article "Spectre Returns! Speculation Attacks using the Return Stack 
Buffer" [1] describes two new (sub-)variants of spectrev2-like attack, 
making use solely of the RSB contents even on CPUs that don't fallback to 
BTB on RSB underflow (Skylake+).

Mitigate userspace-userspace attacks by always unconditionally filling RSB on
context switch when generic spectrev2 mitigation has been enabled.

[1] https://arxiv.org/pdf/1807.07940.pdf

Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---

v1 -> v2: 

	- Fixed typos/capatalization in SpectreRSB name
	- Josh's Reviewed-by

 arch/x86/kernel/cpu/bugs.c | 38 +++++++-------------------------------
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..bc8c43b22460 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
 	return cmd;
 }
 
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
-	    boot_cpu_data.x86 == 6) {
-		switch (boot_cpu_data.x86_model) {
-		case INTEL_FAM6_SKYLAKE_MOBILE:
-		case INTEL_FAM6_SKYLAKE_DESKTOP:
-		case INTEL_FAM6_SKYLAKE_X:
-		case INTEL_FAM6_KABYLAKE_MOBILE:
-		case INTEL_FAM6_KABYLAKE_DESKTOP:
-			return true;
-		}
-	}
-	return false;
-}
-
 static void __init spectre_v2_select_mitigation(void)
 {
 	enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
 	pr_info("%s\n", spectre_v2_strings[mode]);
 
 	/*
-	 * If neither SMEP nor PTI are available, there is a risk of
-	 * hitting userspace addresses in the RSB after a context switch
-	 * from a shallow call stack to a deeper one. To prevent this fill
-	 * the entire RSB, even when using IBRS.
+	 * If spectre v2 protection has been enabled, unconditionally fill
+	 * RSB during a context switch; this protects against two independent
+	 * issues:
 	 *
-	 * Skylake era CPUs have a separate issue with *underflow* of the
-	 * RSB, when they will predict 'ret' targets from the generic BTB.
-	 * The proper mitigation for this is IBRS. If IBRS is not supported
-	 * or deactivated in favour of retpolines the RSB fill on context
-	 * switch is required.
+	 *	- RSB underflow (and switch to BTB) on Skylake+
+	 *	- SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
 	 */
-	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
-		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
-		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
-	}
+	setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+	pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n");
 
 	/* Initialize Indirect Branch Prediction Barrier if supported */
 	if (boot_cpu_has(X86_FEATURE_IBPB)) {
-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v2] x86/bugs: protect against userspace-userspace spectreRSB

[Tim Chen]

On 07/26/2018 04:14 AM, Jiri Kosina wrote:
> From: Jiri Kosina <jkosina@suse.cz>
> 
> The article "Spectre Returns! Speculation Attacks using the Return Stack 
> Buffer" [1] describes two new (sub-)variants of spectrev2-like attack, 
> making use solely of the RSB contents even on CPUs that don't fallback to 
> BTB on RSB underflow (Skylake+).
> 
> Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> context switch when generic spectrev2 mitigation has been enabled.
> 
> [1] https://arxiv.org/pdf/1807.07940.pdf
> 
> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> ---
> 
> v1 -> v2: 
> 
> 	- Fixed typos/capatalization in SpectreRSB name
> 	- Josh's Reviewed-by
> 
>  arch/x86/kernel/cpu/bugs.c | 38 +++++++-------------------------------
>  1 file changed, 7 insertions(+), 31 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> index 5c0ea39311fe..bc8c43b22460 100644
> --- a/arch/x86/kernel/cpu/bugs.c
> +++ b/arch/x86/kernel/cpu/bugs.c
> @@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
>  	return cmd;
>  }
>  
> -/* Check for Skylake-like CPUs (for RSB handling) */
> -static bool __init is_skylake_era(void)
> -{
> -	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> -	    boot_cpu_data.x86 == 6) {
> -		switch (boot_cpu_data.x86_model) {
> -		case INTEL_FAM6_SKYLAKE_MOBILE:
> -		case INTEL_FAM6_SKYLAKE_DESKTOP:
> -		case INTEL_FAM6_SKYLAKE_X:
> -		case INTEL_FAM6_KABYLAKE_MOBILE:
> -		case INTEL_FAM6_KABYLAKE_DESKTOP:
> -			return true;
> -		}
> -	}
> -	return false;
> -}
> -
>  static void __init spectre_v2_select_mitigation(void)
>  {
>  	enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
> @@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
>  	pr_info("%s\n", spectre_v2_strings[mode]);
>  
>  	/*
> -	 * If neither SMEP nor PTI are available, there is a risk of
> -	 * hitting userspace addresses in the RSB after a context switch
> -	 * from a shallow call stack to a deeper one. To prevent this fill
> -	 * the entire RSB, even when using IBRS.
> +	 * If spectre v2 protection has been enabled, unconditionally fill
> +	 * RSB during a context switch; this protects against two independent
> +	 * issues:
>  	 *
> -	 * Skylake era CPUs have a separate issue with *underflow* of the
> -	 * RSB, when they will predict 'ret' targets from the generic BTB.
> -	 * The proper mitigation for this is IBRS. If IBRS is not supported
> -	 * or deactivated in favour of retpolines the RSB fill on context
> -	 * switch is required.
> +	 *	- RSB underflow (and switch to BTB) on Skylake+
> +	 *	- SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
>  	 */
> -	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> -	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> -		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> -		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
> -	}
> +	setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> +	pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n");
>  
>  	/* Initialize Indirect Branch Prediction Barrier if supported */
>  	if (boot_cpu_has(X86_FEATURE_IBPB)) {
> 

Thanks for the patch.  Looks good.  

Acked-by: Tim Chen <tim.c.chen@linux.intel.com>

Tim

Re: [PATCH] x86/bugs: protect against userspace-userspace spectreRSB

[Tim Chen]

On 07/25/2018 10:11 AM, Josh Poimboeuf wrote:
> On Wed, Jul 25, 2018 at 03:50:44PM +0200, Jiri Kosina wrote:
>> On Wed, 25 Jul 2018, Josh Poimboeuf wrote:
>>
>>>> The article "Spectre Returns! Speculation Attacks using the Return Stack
>>>> Buffer" [1] describes two new (sub-)variants of spectrev2-like attack,
>>>> making use solely of the RSB contents even on CPUs that don't fallback to
>>>> BTB on RSB underflow (Skylake+).
>>>>
>>>> Mitigate userspace-userspace attacks by always unconditionally filling RSB on
>>>> context switch when generic spectrev2 mitigation has been enabled.
>>>>
>>>> [1] https://arxiv.org/pdf/1807.07940.pdf
>>>>
>>>> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>>>
>>> While I generally agree with this patch, isn't it odd that we would do
>>> RSB filling on every context switch, but almost never do IBPB?
>>
>> Yeah, I have actually been wondering exactly the same, but that's what we 
>> have been doing so far on SKL+, so I didn't really want to mix this aspect 
>> in.
>>
>> I actually believe that in the name of consistency we should've been doing 
>> the RSB fills under the same conditions we're issuing IBPB even on SKL+; I 
>> can resend a patch that re-adjusts that, if that's the consensus.
> 
> True, in theory it might make more sense to only fill RSB when doing an
> IBPB.  But given the current state of almost never doing IBPB, that
> would be pointless.  RSB is cheap enough that we should just do it
> unconditionally on context switch.
> 
> BTW, I've heard that IBPB actually flushes RSB, though I haven't seen
> that officially documented anywhere.  Not that it matters given the
> current IBPB code.

I think that's correct.  IBPB does flushes the RSB.  But doing
RSB stuffing will be cheaper.

Tim

> 
> BTW^2, there was some discussion a few months back about offloading the
> "when to IBPB" decision to security modules, though I don't think I've
> ever seen official patches for that.
> 
> All that said, this patch is fine until if/when the IBPB strategy gets
> figured out.  RSB filling is cheap.
> 
> Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
> 

Re: [PATCH v2] x86/bugs: protect against userspace-userspace spectreRSB

[Konrad Rzeszutek Wilk]

On Mon, Jul 30, 2018 at 10:56:55AM -0700, Tim Chen wrote:
> On 07/26/2018 04:14 AM, Jiri Kosina wrote:
> > From: Jiri Kosina <jkosina@suse.cz>
> > 
> > The article "Spectre Returns! Speculation Attacks using the Return Stack 
> > Buffer" [1] describes two new (sub-)variants of spectrev2-like attack, 
> > making use solely of the RSB contents even on CPUs that don't fallback to 
> > BTB on RSB underflow (Skylake+).
> > 
> > Mitigate userspace-userspace attacks by always unconditionally filling RSB on
> > context switch when generic spectrev2 mitigation has been enabled.
> > 
> > [1] https://arxiv.org/pdf/1807.07940.pdf
> > 
> > Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>

May I suggest:

CC: stable@vger.kernel.org ?

> > ---
> > 
> > v1 -> v2: 
> > 
> > 	- Fixed typos/capatalization in SpectreRSB name
> > 	- Josh's Reviewed-by
> > 
> >  arch/x86/kernel/cpu/bugs.c | 38 +++++++-------------------------------
> >  1 file changed, 7 insertions(+), 31 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
> > index 5c0ea39311fe..bc8c43b22460 100644
> > --- a/arch/x86/kernel/cpu/bugs.c
> > +++ b/arch/x86/kernel/cpu/bugs.c
> > @@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
> >  	return cmd;
> >  }
> >  
> > -/* Check for Skylake-like CPUs (for RSB handling) */
> > -static bool __init is_skylake_era(void)
> > -{
> > -	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
> > -	    boot_cpu_data.x86 == 6) {
> > -		switch (boot_cpu_data.x86_model) {
> > -		case INTEL_FAM6_SKYLAKE_MOBILE:
> > -		case INTEL_FAM6_SKYLAKE_DESKTOP:
> > -		case INTEL_FAM6_SKYLAKE_X:
> > -		case INTEL_FAM6_KABYLAKE_MOBILE:
> > -		case INTEL_FAM6_KABYLAKE_DESKTOP:
> > -			return true;
> > -		}
> > -	}
> > -	return false;
> > -}
> > -
> >  static void __init spectre_v2_select_mitigation(void)
> >  {
> >  	enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
> > @@ -390,22 +373,15 @@ static void __init spectre_v2_select_mitigation(void)
> >  	pr_info("%s\n", spectre_v2_strings[mode]);
> >  
> >  	/*
> > -	 * If neither SMEP nor PTI are available, there is a risk of
> > -	 * hitting userspace addresses in the RSB after a context switch
> > -	 * from a shallow call stack to a deeper one. To prevent this fill
> > -	 * the entire RSB, even when using IBRS.
> > +	 * If spectre v2 protection has been enabled, unconditionally fill
> > +	 * RSB during a context switch; this protects against two independent
> > +	 * issues:
> >  	 *
> > -	 * Skylake era CPUs have a separate issue with *underflow* of the
> > -	 * RSB, when they will predict 'ret' targets from the generic BTB.
> > -	 * The proper mitigation for this is IBRS. If IBRS is not supported
> > -	 * or deactivated in favour of retpolines the RSB fill on context
> > -	 * switch is required.
> > +	 *	- RSB underflow (and switch to BTB) on Skylake+
> > +	 *	- SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
> >  	 */
> > -	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
> > -	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
> > -		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > -		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
> > -	}
> > +	setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
> > +	pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n");
> >  
> >  	/* Initialize Indirect Branch Prediction Barrier if supported */
> >  	if (boot_cpu_has(X86_FEATURE_IBPB)) {
> > 
> 
> Thanks for the patch.  Looks good.  
> 
> Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
> 
> Tim

[tip:x86/pti] x86/speculation: Protect against userspace-userspace spectreRSB

[tip-bot for Jiri Kosina]

Commit-ID:  fdf82a7856b32d905c39afc85e34364491e46346
Gitweb:     https://git.kernel.org/tip/fdf82a7856b32d905c39afc85e34364491e46346
Author:     Jiri Kosina <jkosina@suse.cz>
AuthorDate: Thu, 26 Jul 2018 13:14:55 +0200
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 31 Jul 2018 00:45:15 +0200

x86/speculation: Protect against userspace-userspace spectreRSB

The article "Spectre Returns! Speculation Attacks using the Return Stack 
Buffer" [1] describes two new (sub-)variants of spectrev2-like attacks, 
making use solely of the RSB contents even on CPUs that don't fallback to 
BTB on RSB underflow (Skylake+).

Mitigate userspace-userspace attacks by always unconditionally filling RSB on
context switch when the generic spectrev2 mitigation has been enabled.

[1] https://arxiv.org/pdf/1807.07940.pdf

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/nycvar.YFH.7.76.1807261308190.997@cbobk.fhfr.pm

---
 arch/x86/kernel/cpu/bugs.c | 38 +++++++-------------------------------
 1 file changed, 7 insertions(+), 31 deletions(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 5c0ea39311fe..bc8c43b22460 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -313,23 +313,6 @@ static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
 	return cmd;
 }
 
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
-{
-	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
-	    boot_cpu_data.x86 == 6) {
-		switch (boot_cpu_data.x86_model) {
-		case INTEL_FAM6_SKYLAKE_MOBILE:
-		case INTEL_FAM6_SKYLAKE_DESKTOP:
-		case INTEL_FAM6_SKYLAKE_X:
-		case INTEL_FAM6_KABYLAKE_MOBILE:
-		case INTEL_FAM6_KABYLAKE_DESKTOP:
-			return true;
-		}
-	}
-	return false;
-}
-
 static void __init spectre_v2_select_mitigation(void)
 {
 	enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -390,22 +373,15 @@ retpoline_auto:
 	pr_info("%s\n", spectre_v2_strings[mode]);
 
 	/*
-	 * If neither SMEP nor PTI are available, there is a risk of
-	 * hitting userspace addresses in the RSB after a context switch
-	 * from a shallow call stack to a deeper one. To prevent this fill
-	 * the entire RSB, even when using IBRS.
+	 * If spectre v2 protection has been enabled, unconditionally fill
+	 * RSB during a context switch; this protects against two independent
+	 * issues:
 	 *
-	 * Skylake era CPUs have a separate issue with *underflow* of the
-	 * RSB, when they will predict 'ret' targets from the generic BTB.
-	 * The proper mitigation for this is IBRS. If IBRS is not supported
-	 * or deactivated in favour of retpolines the RSB fill on context
-	 * switch is required.
+	 *	- RSB underflow (and switch to BTB) on Skylake+
+	 *	- SpectreRSB variant of spectre v2 on X86_BUG_SPECTRE_V2 CPUs
 	 */
-	if ((!boot_cpu_has(X86_FEATURE_PTI) &&
-	     !boot_cpu_has(X86_FEATURE_SMEP)) || is_skylake_era()) {
-		setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
-		pr_info("Spectre v2 mitigation: Filling RSB on context switch\n");
-	}
+	setup_force_cpu_cap(X86_FEATURE_RSB_CTXSW);
+	pr_info("Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch\n");
 
 	/* Initialize Indirect Branch Prediction Barrier if supported */
 	if (boot_cpu_has(X86_FEATURE_IBPB)) {