historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
* Slow Randomizing Boosts Denial of Service - Bulletin #2
@ 2020-04-28 15:48 Thomas Gleixner
  2020-05-04 23:41 ` [MODERATED] " Ben Hutchings
  2020-05-05 19:29 ` Borislav Petkov
  0 siblings, 2 replies; 4+ messages in thread
From: Thomas Gleixner @ 2020-04-28 15:48 UTC (permalink / raw)
  To: speck

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Folks!

I've merged the documentation update from Josh into the master branch of
the speck git repository at:

   cvs.ou.linutronix.de:linux/speck/linux

The stable branches linux-5.6.y, linux-5.4.y, linux-4.19.y and
linux-4.14.y have been updated as well.

The badly smelling linux-4.9.y and linux-4.4.y branches have the backports provided
by Mark.

A tarball with git bundles is attached.

Thanks,

	tglx

[-- Attachment #2: srbds-2.tar.xz --]
[-- Type: application/x-xz, Size: 63352 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [MODERATED] Re: Slow Randomizing Boosts Denial of Service - Bulletin #2
  2020-04-28 15:48 Slow Randomizing Boosts Denial of Service - Bulletin #2 Thomas Gleixner
@ 2020-05-04 23:41 ` Ben Hutchings
  2020-05-05 19:29 ` Borislav Petkov
  1 sibling, 0 replies; 4+ messages in thread
From: Ben Hutchings @ 2020-05-04 23:41 UTC (permalink / raw)
  To: speck

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

On Tue, 2020-04-28 at 17:48 +0200, speck for Thomas Gleixner wrote:
> Folks!
> 
> I've merged the documentation update from Josh into the master branch of
> the speck git repository at:
> 
>    cvs.ou.linutronix.de:linux/speck/linux
> 
> The stable branches linux-5.6.y, linux-5.4.y, linux-4.19.y and
> linux-4.14.y have been updated as well.
> 
> The badly smelling linux-4.9.y and linux-4.4.y branches have the backports provided
> by Mark.
> 
> A tarball with git bundles is attached.

I noticed that the backports of "x86/cpu: Add a steppings field to
struct x86_cpu_id" to 5.4 and 5.6 add a couple of unused macros to the
top of <arch/x86/include/asm/cpu_device_id.h>:

+#define X86_CENTAUR_FAM6_C7_D          0xd
+#define X86_CENTAUR_FAM6_NANO          0xf

It looks like a bogus conflict resolution.  The backports to older
versions don't have these.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [MODERATED] Re: Slow Randomizing Boosts Denial of Service - Bulletin #2
  2020-04-28 15:48 Slow Randomizing Boosts Denial of Service - Bulletin #2 Thomas Gleixner
  2020-05-04 23:41 ` [MODERATED] " Ben Hutchings
@ 2020-05-05 19:29 ` Borislav Petkov
  2020-05-05 21:31   ` mark gross
  1 sibling, 1 reply; 4+ messages in thread
From: Borislav Petkov @ 2020-05-05 19:29 UTC (permalink / raw)
  To: speck

On Tue, Apr 28, 2020 at 05:48:49PM +0200, speck for Thomas Gleixner wrote:
> Folks!
> 
> I've merged the documentation update from Josh into the master branch of
> the speck git repository at:
> 
>    cvs.ou.linutronix.de:linux/speck/linux

Ok, since the CRD has been pushed by a ~month, we probably should start
merging the non-critical pieces because we have users for them and
there's no point in letting them rot in an out-of-tree repo.

Of course, we won't change the SHA1's so that no ongoing backports are
disrupted.

Thus, looking at:

  e9d7144597b1 ("x86/cpu: Add a steppings field to struct x86_cpu_id")

for example, it doesn't have any text in there which hints at anything
NDA and so we can queue it for upstreaming now along with those below
and thus slim down the SRBDS queue even more. I.e., it will have only
three patches after this.

Thx.

---
From: Borislav Petkov <bp@suse.de>
Date: Tue, 5 May 2020 19:25:08 +0200
Subject: [PATCH 1/2] x86/cpu: Add a X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS() macro

... to match Intel family 6 CPUs with steppings.

Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/include/asm/cpu_device_id.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
index 10426cd56dca..eb8fcede9e3b 100644
--- a/arch/x86/include/asm/cpu_device_id.h
+++ b/arch/x86/include/asm/cpu_device_id.h
@@ -160,6 +160,10 @@
 #define X86_MATCH_INTEL_FAM6_MODEL(model, data)				\
 	X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, INTEL_FAM6_##model, data)
 
+#define X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(model, steppings, data)	\
+	X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
+						     steppings, X86_FEATURE_ANY, data)
+
 /*
  * Match specific microcode revisions.
  *
-- 
2.21.0

---
From: Borislav Petkov <bp@suse.de>
Date: Tue, 5 May 2020 19:27:16 +0200
Subject: [PATCH 2/2] x86/apic: Convert the TSC deadline timer matching to steppings macro

... and get rid of the function pointers which would spit out the
microcode revision based on the CPU stepping.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 arch/x86/kernel/apic/apic.c | 57 ++++++++-----------------------------
 1 file changed, 12 insertions(+), 45 deletions(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index e53dda210cd7..4b1d31be50b4 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -544,46 +544,20 @@ static struct clock_event_device lapic_clockevent = {
 };
 static DEFINE_PER_CPU(struct clock_event_device, lapic_events);
 
-static __init u32 hsx_deadline_rev(void)
-{
-	switch (boot_cpu_data.x86_stepping) {
-	case 0x02: return 0x3a; /* EP */
-	case 0x04: return 0x0f; /* EX */
-	}
-
-	return ~0U;
-}
-
-static __init u32 bdx_deadline_rev(void)
-{
-	switch (boot_cpu_data.x86_stepping) {
-	case 0x02: return 0x00000011;
-	case 0x03: return 0x0700000e;
-	case 0x04: return 0x0f00000c;
-	case 0x05: return 0x0e000003;
-	}
-
-	return ~0U;
-}
-
-static __init u32 skx_deadline_rev(void)
-{
-	switch (boot_cpu_data.x86_stepping) {
-	case 0x03: return 0x01000136;
-	case 0x04: return 0x02000014;
-	}
+static const struct x86_cpu_id deadline_match[] __initconst = {
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(HASWELL_X, X86_STEPPINGS(0x2, 0x2), 0x3a), /* EP */
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(HASWELL_X, X86_STEPPINGS(0x4, 0x4), 0x0f), /* EX */
 
-	if (boot_cpu_data.x86_stepping > 4)
-		return 0;
+	X86_MATCH_INTEL_FAM6_MODEL( BROADWELL_X,	0x0b000020),
 
-	return ~0U;
-}
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x2, 0x2), 0x00000011),
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x3, 0x3), 0x0700000e),
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x4, 0x4), 0x0f00000c),
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x5, 0x5), 0x0e000003),
 
-static const struct x86_cpu_id deadline_match[] __initconst = {
-	X86_MATCH_INTEL_FAM6_MODEL( HASWELL_X,		&hsx_deadline_rev),
-	X86_MATCH_INTEL_FAM6_MODEL( BROADWELL_X,	0x0b000020),
-	X86_MATCH_INTEL_FAM6_MODEL( BROADWELL_D,	&bdx_deadline_rev),
-	X86_MATCH_INTEL_FAM6_MODEL( SKYLAKE_X,		&skx_deadline_rev),
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(SKYLAKE_X, X86_STEPPINGS(0x3, 0x3), 0x01000136),
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(SKYLAKE_X, X86_STEPPINGS(0x4, 0x4), 0x02000014),
+	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(SKYLAKE_X, X86_STEPPINGS(0x5, 0xf), 0),
 
 	X86_MATCH_INTEL_FAM6_MODEL( HASWELL,		0x22),
 	X86_MATCH_INTEL_FAM6_MODEL( HASWELL_L,		0x20),
@@ -615,14 +589,7 @@ static __init bool apic_validate_deadline_timer(void)
 	if (!m)
 		return true;
 
-	/*
-	 * Function pointers will have the MSB set due to address layout,
-	 * immediate revisions will not.
-	 */
-	if ((long)m->driver_data < 0)
-		rev = ((u32 (*)(void))(m->driver_data))();
-	else
-		rev = (u32)m->driver_data;
+	rev = (u32)m->driver_data;
 
 	if (boot_cpu_data.microcode >= rev)
 		return true;
-- 
2.21.0

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [MODERATED] Re: Slow Randomizing Boosts Denial of Service - Bulletin #2
  2020-05-05 19:29 ` Borislav Petkov
@ 2020-05-05 21:31   ` mark gross
  0 siblings, 0 replies; 4+ messages in thread
From: mark gross @ 2020-05-05 21:31 UTC (permalink / raw)
  To: speck

On Tue, May 05, 2020 at 09:29:07PM +0200, speck for Borislav Petkov wrote:
> On Tue, Apr 28, 2020 at 05:48:49PM +0200, speck for Thomas Gleixner wrote:
> > Folks!
> > 
> > I've merged the documentation update from Josh into the master branch of
> > the speck git repository at:
> > 
> >    cvs.ou.linutronix.de:linux/speck/linux
> 
> Ok, since the CRD has been pushed by a ~month, we probably should start
> merging the non-critical pieces because we have users for them and
> there's no point in letting them rot in an out-of-tree repo.
> 
> Of course, we won't change the SHA1's so that no ongoing backports are
> disrupted.
> 
> Thus, looking at:
> 
>   e9d7144597b1 ("x86/cpu: Add a steppings field to struct x86_cpu_id")
> 
> for example, it doesn't have any text in there which hints at anything
> NDA and so we can queue it for upstreaming now along with those below
> and thus slim down the SRBDS queue even more. I.e., it will have only
> three patches after this.
> 
> Thx.
Look good to me.

--mark

> 
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Tue, 5 May 2020 19:25:08 +0200
> Subject: [PATCH 1/2] x86/cpu: Add a X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS() macro
> 
> ... to match Intel family 6 CPUs with steppings.
> 
> Signed-off-by: Borislav Petkov <bp@suse.de>
> ---
>  arch/x86/include/asm/cpu_device_id.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h
> index 10426cd56dca..eb8fcede9e3b 100644
> --- a/arch/x86/include/asm/cpu_device_id.h
> +++ b/arch/x86/include/asm/cpu_device_id.h
> @@ -160,6 +160,10 @@
>  #define X86_MATCH_INTEL_FAM6_MODEL(model, data)				\
>  	X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, INTEL_FAM6_##model, data)
>  
> +#define X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(model, steppings, data)	\
> +	X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \
> +						     steppings, X86_FEATURE_ANY, data)
> +
>  /*
>   * Match specific microcode revisions.
>   *
> -- 
> 2.21.0
> 
> ---
> From: Borislav Petkov <bp@suse.de>
> Date: Tue, 5 May 2020 19:27:16 +0200
> Subject: [PATCH 2/2] x86/apic: Convert the TSC deadline timer matching to steppings macro
> 
> ... and get rid of the function pointers which would spit out the
> microcode revision based on the CPU stepping.
> 
> Signed-off-by: Borislav Petkov <bp@suse.de>
> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
>  arch/x86/kernel/apic/apic.c | 57 ++++++++-----------------------------
>  1 file changed, 12 insertions(+), 45 deletions(-)
> 
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index e53dda210cd7..4b1d31be50b4 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -544,46 +544,20 @@ static struct clock_event_device lapic_clockevent = {
>  };
>  static DEFINE_PER_CPU(struct clock_event_device, lapic_events);
>  
> -static __init u32 hsx_deadline_rev(void)
> -{
> -	switch (boot_cpu_data.x86_stepping) {
> -	case 0x02: return 0x3a; /* EP */
> -	case 0x04: return 0x0f; /* EX */
> -	}
> -
> -	return ~0U;
> -}
> -
> -static __init u32 bdx_deadline_rev(void)
> -{
> -	switch (boot_cpu_data.x86_stepping) {
> -	case 0x02: return 0x00000011;
> -	case 0x03: return 0x0700000e;
> -	case 0x04: return 0x0f00000c;
> -	case 0x05: return 0x0e000003;
> -	}
> -
> -	return ~0U;
> -}
> -
> -static __init u32 skx_deadline_rev(void)
> -{
> -	switch (boot_cpu_data.x86_stepping) {
> -	case 0x03: return 0x01000136;
> -	case 0x04: return 0x02000014;
> -	}
> +static const struct x86_cpu_id deadline_match[] __initconst = {
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(HASWELL_X, X86_STEPPINGS(0x2, 0x2), 0x3a), /* EP */
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(HASWELL_X, X86_STEPPINGS(0x4, 0x4), 0x0f), /* EX */
>  
> -	if (boot_cpu_data.x86_stepping > 4)
> -		return 0;
> +	X86_MATCH_INTEL_FAM6_MODEL( BROADWELL_X,	0x0b000020),
>  
> -	return ~0U;
> -}
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x2, 0x2), 0x00000011),
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x3, 0x3), 0x0700000e),
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x4, 0x4), 0x0f00000c),
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(BROADWELL_D, X86_STEPPINGS(0x5, 0x5), 0x0e000003),
>  
> -static const struct x86_cpu_id deadline_match[] __initconst = {
> -	X86_MATCH_INTEL_FAM6_MODEL( HASWELL_X,		&hsx_deadline_rev),
> -	X86_MATCH_INTEL_FAM6_MODEL( BROADWELL_X,	0x0b000020),
> -	X86_MATCH_INTEL_FAM6_MODEL( BROADWELL_D,	&bdx_deadline_rev),
> -	X86_MATCH_INTEL_FAM6_MODEL( SKYLAKE_X,		&skx_deadline_rev),
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(SKYLAKE_X, X86_STEPPINGS(0x3, 0x3), 0x01000136),
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(SKYLAKE_X, X86_STEPPINGS(0x4, 0x4), 0x02000014),
> +	X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(SKYLAKE_X, X86_STEPPINGS(0x5, 0xf), 0),
>  
>  	X86_MATCH_INTEL_FAM6_MODEL( HASWELL,		0x22),
>  	X86_MATCH_INTEL_FAM6_MODEL( HASWELL_L,		0x20),
> @@ -615,14 +589,7 @@ static __init bool apic_validate_deadline_timer(void)
>  	if (!m)
>  		return true;
>  
> -	/*
> -	 * Function pointers will have the MSB set due to address layout,
> -	 * immediate revisions will not.
> -	 */
> -	if ((long)m->driver_data < 0)
> -		rev = ((u32 (*)(void))(m->driver_data))();
> -	else
> -		rev = (u32)m->driver_data;
> +	rev = (u32)m->driver_data;
>  
>  	if (boot_cpu_data.microcode >= rev)
>  		return true;
> -- 
> 2.21.0
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-05-05 21:32 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-28 15:48 Slow Randomizing Boosts Denial of Service - Bulletin #2 Thomas Gleixner
2020-05-04 23:41 ` [MODERATED] " Ben Hutchings
2020-05-05 19:29 ` Borislav Petkov
2020-05-05 21:31   ` mark gross

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).