linux-stable.git/arch/x86/kernel/cpu/microcode, branch v3.18.78

x86/microcode/intel: Guard against stack overflow in the loader

2015-07-13T12:50:05+00:00

[ Upstream commit f84598bd7c851f8b0bf8cd0d7c3be0d73c432ff4 ]

mc_saved_tmp is a static array allocated on the stack, we need to make
sure mc_saved_count stays within its bounds, otherwise we're overflowing
the stack in _save_mc(). A specially crafted microcode header could lead
to a kernel crash or potentially kernel execution.

Signed-off-by: Quentin Casasnovas 
Cc: "H. Peter Anvin" 
Cc: Fenghua Yu 
Link: http://lkml.kernel.org/r/1422964824-22056-1-git-send-email-quentin.casasnovas@oracle.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Sasha Levin

x86, microcode: Return error from driver init code when loader is disabled

2015-02-11T07:00:56+00:00

commit da63865a01c6384d459464e5165d95d4f04878d8 upstream.

Commits 65cef1311d5d ("x86, microcode: Add a disable chicken bit") and
a18a0f6850d4 ("x86, microcode: Don't initialize microcode code on
paravirt") allow microcode driver skip initialization when microcode
loading is not permitted.

However, they don't prevent the driver from being loaded since the
init code returns 0. If at some point later the driver gets unloaded
this will result in an oops while trying to deregister the (never
registered) device.

To avoid this, make init code return an error on paravirt or when
microcode loading is disabled. The driver will then never be loaded.

Signed-off-by: Boris Ostrovsky 
Link: http://lkml.kernel.org/r/1422411669-25147-1-git-send-email-boris.ostrovsky@oracle.com
Reported-by: James Digwall 
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

x86/microcode/intel: Fish out the stashed microcode for the BSP

2015-01-08T18:30:22+00:00

commit 25cdb9c86826f8d035d8aaa07fc36832e76bd8a0 upstream.

I'm such a moron! The simple solution of saving the BSP patch
for use on resume was too simple (and wrong!), hint:
sizeof(struct microcode_intel).

What needs to be done instead is to fish out the microcode patch
we have stashed previously and apply that on the BSP in case the
late loader hasn't been utilized.

So do that instead.

Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/20141208110820.GB20057@pd.tnic
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, microcode: Reload microcode on resume

2015-01-08T18:30:22+00:00

commit fbae4ba8c4a387e306adc9c710e5c225cece7678 upstream.

Normally, we do reapply microcode on resume. However, in the cases where
that microcode comes from the early loader and the late loader hasn't
been utilized yet, there's no easy way for us to go and apply the patch
applied during boot by the early loader.

Thus, reuse the patch stashed by the early loader for the BSP.

Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

x86, microcode: Don't initialize microcode code on paravirt

2015-01-08T18:30:22+00:00

commit a18a0f6850d4b286a5ebf02cd5b22fe496b86349 upstream.

Paravirtual guests are not expected to load microcode into processors
and therefore it is not necessary to initialize microcode loading
logic.

In fact, under certain circumstances initializing this logic may cause
the guest to crash. Specifically, 32-bit kernels use __pa_nodebug()
macro which does not work in Xen (the code path that leads to this macro
happens during resume when we call mc_bp_resume()->load_ucode_ap()
->check_loader_disabled_ap())

Signed-off-by: Boris Ostrovsky 
Link: http://lkml.kernel.org/r/1417469264-31470-1-git-send-email-boris.ostrovsky@oracle.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

x86, microcode, intel: Drop unused parameter

2015-01-08T18:30:22+00:00

commit 47768626c6db42cd06ff077ba12dd2cb10ab818b upstream.

apply_microcode_early() doesn't use mc_saved_data, kill it.

Signed-off-by: Borislav Petkov 
Signed-off-by: Greg Kroah-Hartman

x86, microcode, AMD: Do not use smp_processor_id() in preemtible context

2015-01-08T18:30:22+00:00

commit 2ef84b3bb97f03332f0c1edb4466b1750dcf97b5 upstream.

Hand down the cpu number instead, otherwise lockdep screams when doing

echo 1 > /sys/devices/system/cpu/microcode/reload.

BUG: using smp_processor_id() in preemptible [00000000] code: amd64-microcode/2470
caller is debug_smp_processor_id+0x12/0x20
CPU: 1 PID: 2470 Comm: amd64-microcode Not tainted 3.18.0-rc6+ #26
...

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1417428741-4501-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86, microcode: Limit the microcode reloading to 64-bit for now

2014-12-01T09:55:08+00:00

First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001

The problem there was that microcode patches are not being reapplied
after suspend-to-ram. It was important to reapply them, though, because
of for example Haswell's TSX erratum which disabled TSX instructions
with a microcode patch.

A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode
on resume") but, as it is often the case, simple fixes are too
simple. This one causes 32-bit resume to fail:

https://bugzilla.kernel.org/show_bug.cgi?id=88391

Properly fixing this would require more involved changes for which it
is too late now, right before the merge window. Thus, limit this to
64-bit only temporarily.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/1417353999-32236-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner

x86, microcode: Update BSPs microcode on resume

2014-11-18T17:32:24+00:00

In the situation when we apply early microcode but do *not* apply late
microcode, we fail to update the BSP's microcode on resume because we
haven't initialized the uci->mc microcode pointer. So, in order to
alleviate that, we go and dig out the stashed microcode patch during
early boot. It is basically the same thing that is done on the APs early
during boot so do that too here.

Tested-by: alex.schnaidt@gmail.com
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001
Cc: Henrique de Moraes Holschuh 
Cc: Fenghua Yu 
Cc:  # v3.9
Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic
Signed-off-by: Thomas Gleixner

x86, microcode, AMD: Fix ucode patch stashing on 32-bit

2014-11-10T12:50:55+00:00

Save the patch while we're running on the BSP instead of later, before
the initrd has been jettisoned. More importantly, on 32-bit we need to
access the physical address instead of the virtual.

This way we actually do find it on the APs instead of having to go
through the initrd each time.

Tested-by: Richard Hendershot 
Fixes: 5335ba5cf475 ("x86, microcode, AMD: Fix early ucode loading")
Cc:  # v3.13+
Signed-off-by: Borislav Petkov