Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1560850 > unrolled thread

[PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer optimization

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer optimization Borislav Petkov <bp@alien8.de> - 2017-01-17 18:50 +0100
    Re: [PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer  optimization Thomas Gleixner <tglx@linutronix.de> - 2017-01-17 21:10 +0100

#1560850 — [PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer optimization

From: Borislav Petkov <bp@suse.de>

This was meant to save us the scanning of the microcode containter in
the initrd since the first AP had already done that but it can also hurt
us:

Imagine a single hyperthreaded CPU (Intel(R) Atom(TM) CPU N270 for
example) which updates the microcode on the BSP but since the microcode
engine is shared between the two threads, the update on CPU1 doesn't
happen because it has already happened on CPU0 and we don't find a newer
microcode revision.

Which doesn't set the intel_ucode_patch pointer and at initrd
jettisoning time and we don't save the microcode patch for later
application.

Now, when we suspend to RAM, the loaded microcode gets cleared so we
need to reload but there's no patch saved in the cache.

Removing this optimization fixes this issue and all is fine and dandy.

Signed-off-by: Borislav Petkov <bp@suse.de>
---
 arch/x86/kernel/cpu/microcode/intel.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 3f329b74e040..8325d8a09ab0 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -41,7 +41,7 @@
 
 static const char ucode_path[] = "kernel/x86/microcode/GenuineIntel.bin";
 
-/* Current microcode patch used in early patching */
+/* Current microcode patch used in early patching on the APs. */
 struct microcode_intel *intel_ucode_patch;
 
 static inline bool cpu_signatures_match(unsigned int s1, unsigned int p1,
@@ -607,12 +607,6 @@ int __init save_microcode_in_initrd_intel(void)
 	struct ucode_cpu_info uci;
 	struct cpio_data cp;
 
-	/*
-	 * AP loading didn't find any microcode patch, no need to save anything.
-	 */
-	if (!intel_ucode_patch || IS_ERR(intel_ucode_patch))
-		return 0;
-
 	if (!load_builtin_intel_microcode(&cp))
 		cp = find_microcode_in_initrd(ucode_path, false);
 
@@ -628,7 +622,6 @@ int __init save_microcode_in_initrd_intel(void)
 	return 0;
 }
 
-
 /*
  * @res_patch, output: a pointer to the patch we found.
  */
-- 
2.11.0

[toc] | [next] | [standalone]

#1560975 — Re: [PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer optimization

On Tue, 17 Jan 2017, Borislav Petkov wrote:

> From: Borislav Petkov <bp@suse.de>
> 
> This was meant to save us the scanning of the microcode containter in
> the initrd since the first AP had already done that but it can also hurt
> us:
> 
> Imagine a single hyperthreaded CPU (Intel(R) Atom(TM) CPU N270 for
> example) which updates the microcode on the BSP but since the microcode
> engine is shared between the two threads, the update on CPU1 doesn't
> happen because it has already happened on CPU0 and we don't find a newer
> microcode revision.
> 
> Which doesn't set the intel_ucode_patch pointer and at initrd
> jettisoning time and we don't save the microcode patch for later
> application.
> 
> Now, when we suspend to RAM, the loaded microcode gets cleared so we
> need to reload but there's no patch saved in the cache.
> 
> Removing this optimization fixes this issue and all is fine and dandy.
> 
> Signed-off-by: Borislav Petkov <bp@suse.de>

So this one needs to go into x86/urgent

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web