linux.git/arch/x86/kernel/cpu/microcode, branch v4.20

Merge branches 'x86/early-printk', 'x86/microcode' and 'core/objtool' into x86/urgent, to pick up simple topic branches

2018-10-29T06:13:09+00:00

Signed-off-by: Ingo Molnar

x86/microcode: Update the new microcode revision unconditionally

2018-09-02T12:10:54+00:00

Handle the case where microcode gets loaded on the BSP's hyperthread
sibling first and the boot_cpu_data's microcode revision doesn't get
updated because of early exit due to the siblings sharing a microcode
engine.

For that, simply write the updated revision on all CPUs unconditionally.

Signed-off-by: Filippo Sironi 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: prarit@redhat.com
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1533050970-14385-1-git-send-email-sironi@amazon.de

x86/microcode: Make sure boot_cpu_data.microcode is up-to-date

2018-09-02T12:10:54+00:00

When preparing an MCE record for logging, boot_cpu_data.microcode is used
to read out the microcode revision on the box.

However, on systems where late microcode update has happened, the microcode
revision output in a MCE log record is wrong because
boot_cpu_data.microcode is not updated when the microcode gets updated.

But, the microcode revision saved in boot_cpu_data's microcode member
should be kept up-to-date, regardless, for consistency.

Make it so.

Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check records")
Signed-off-by: Prarit Bhargava 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: Tony Luck 
Cc: sironi@amazon.de
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180731112739.32338-1-prarit@redhat.com

x86/microcode: Make revision and processor flags world-readable

2018-09-02T12:09:13+00:00

The microcode revision is already readable for non-root users via
/proc/cpuinfo. Thus, there's no reason to keep the same information
readable by root only in /sys/devices/system/cpu/cpuX/microcode/.

Make .../processor_flags world-readable too, while at it.

Reported-by: Tim Burgess 
Signed-off-by: Jacek Tomaka 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180825035039.14409-1-jacekt@dugeo.com

x86/microcode: Allow late microcode loading with SMT disabled

2018-08-10T07:32:15+00:00

The kernel unnecessarily prevents late microcode loading when SMT is
disabled.  It should be safe to allow it if all the primary threads are
online.

Signed-off-by: Josh Poimboeuf 
Acked-by: Borislav Petkov 
Signed-off-by: David Woodhouse

x86/microcode/intel: Fix memleak in save_microcode_patch()

2018-06-22T12:42:59+00:00

Free useless ucode_patch entry when it's replaced.

[ bp: Drop the memfree_patch() two-liner. ]

Signed-off-by: Zhenzhong Duan 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Cc: Srinivas REDDY Eeda 
Link: http://lkml.kernel.org/r/888102f0-fd22-459d-b090-a1bd8a00cb2b@default

x86/microcode: Make the late update update_lock a raw lock for RT

2018-05-27T19:50:09+00:00

__reload_late() is called from stop_machine context and thus cannot
acquire a non-raw spinlock on PREEMPT_RT.

Signed-off-by: Scott Wood 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Acked-by: Thomas Gleixner 
Cc: Ashok Raj 
Cc: Clark Williams 
Cc: Pei Zhang 
Cc: x86-ml 
Link: http://lkml.kernel.org/r/20180524154420.24455-1-swood@redhat.com

x86/microcode: Do not exit early from __reload_late()

2018-04-24T07:48:22+00:00

Vitezslav reported a case where the

  "Timeout during microcode update!"

panic would hit. After a deeper look, it turned out that his .config had
CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a
no-op.

When that happened, the discovered microcode patch wasn't saved into the
cache and the late loading path wouldn't find any.

This, then, lead to early exit from __reload_late() and thus CPUs waiting
until the timeout is reached, leading to the panic.

In hindsight, that function should have been written so it does not return
before the post-synchronization. Oh well, I know better now...

Fixes: bb8c13d61a62 ("x86/microcode: Fix CPU synchronization routine")
Reported-by: Vitezslav Samel 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Tested-by: Vitezslav Samel 
Tested-by: Ashok Raj 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180418081140.GA2439@pc11.op.pod.cz
Link: https://lkml.kernel.org/r/20180421081930.15741-2-bp@alien8.de

x86/microcode/intel: Save microcode patch unconditionally

2018-04-24T07:48:22+00:00

save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the
generic_load_microcode() path saves the microcode patches it has found into
the cache of patches which is used for late loading too. Regardless of
whether CPU hotplug is used or not.

Make the saving unconditional so that late loading can find the proper
patch.

Reported-by: Vitezslav Samel 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Tested-by: Vitezslav Samel 
Tested-by: Ashok Raj 
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20180418081140.GA2439@pc11.op.pod.cz
Link: https://lkml.kernel.org/r/20180421081930.15741-1-bp@alien8.de

Documentation: Fix early-microcode.txt references after file rename

2018-03-27T07:51:23+00:00

The file Documentation/x86/early-microcode.txt was renamed to
Documentation/x86/microcode.txt in 0e3258753f81, but it was still
referenced by its old name in a three places:

* Documentation/x86/00-INDEX
* arch/x86/Kconfig
* arch/x86/kernel/cpu/microcode/amd.c

This commit updates these references accordingly.

Fixes: 0e3258753f81 ("x86/microcode: Document the three loading methods")
Signed-off-by: Jaak Ristioja 
Signed-off-by: Jiri Kosina