linux.git/arch/x86/kernel/cpu/microcode/amd.c, branch v4.18

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

x86/microcode: Attempt late loading only when new microcode is present

2018-03-16T19:55:51+00:00

Return UCODE_NEW from the scanning functions to denote that new microcode
was found and only then attempt the expensive synchronization dance.

Reported-by: Emanuel Czirai 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Tested-by: Emanuel Czirai 
Tested-by: Ashok Raj 
Tested-by: Tom Lendacky 
Link: https://lkml.kernel.org/r/20180314183615.17629-1-bp@alien8.de

x86/microcode: Propagate return value from updating functions

2018-02-17T07:43:55+00:00

... so that callers can know when microcode was updated and act
accordingly.

Tested-by: Ashok Raj 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ashok Raj 
Cc: Andy Lutomirski 
Cc: Arjan van de Ven 
Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Dave Hansen 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20180216112640.11554-2-bp@alien8.de
Signed-off-by: Ingo Molnar

x86/microcode/AMD: Add support for fam17h microcode loading

2017-12-06T11:27:24+00:00

The size for the Microcode Patch Block (MPB) for an AMD family 17h
processor is 3200 bytes.  Add a #define for fam17h so that it does
not default to 2048 bytes and fail a microcode load/update.

Signed-off-by: Tom Lendacky 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar

x86/microcode/AMD: Free unneeded patch before exit from update_cache()

2017-07-25T09:26:19+00:00

verify_and_add_patch() allocates memory for a microcode patch and hands
it down to be added to the cache of patches. However, if the cache
already has the latest patch, the newly allocated one needs to be freed
before returning. Do that.

This issue has been found by kmemleak:

  unreferenced object 0xffff88010e780b40 (size 32):
    comm "bash", pid 860, jiffies 4294690939 (age 29.297s)
    backtrace:
       kmemleak_alloc
       kmem_cache_alloc_trace
       load_microcode_amd.isra.0
       request_microcode_amd
       reload_store
       dev_attr_store
       sysfs_kf_write
       kernfs_fop_write
       __vfs_write
       vfs_write
       SyS_write
       do_syscall_64
       return_from_SYSCALL_64
       0xffffffffffffffff

  (gdb) list *0xffffffff81050d60
  0xffffffff81050d60 is in load_microcode_amd
                (arch/x86/kernel/cpu/microcode/amd.c:616).

which is this:

	patch = kzalloc(sizeof(*patch), GFP_KERNEL);
-->	if (!patch) {
		pr_err("Patch allocation failure.\n");
		return -EINVAL;
	}

Signed-off-by: Shu Wang 
[ Rewrite commit message. ]
Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: chuhu@redhat.com
Cc: liwang@redhat.com
Link: http://lkml.kernel.org/r/20170724101228.17326-2-bp@alien8.de
Signed-off-by: Ingo Molnar

x86/microcode: Make a couple of symbols static

2017-06-26T13:57:37+00:00

The helper function __load_ucode_amd() and pointer intel_ucode_patch do
not need to be in global scope, so make them static.

Fixes those sparse warnings:
"symbol '__load_ucode_amd' was not declared. Should it be static?"
"symbol 'intel_ucode_patch' was not declared. Should it be static?"

Signed-off-by: Colin Ian King 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170622095736.11937-1-colin.king@canonical.com

x86/microcode/AMD: Change load_microcode_amd()'s param to bool to fix preemptibility bug

2017-05-29T06:22:48+00:00

With CONFIG_DEBUG_PREEMPT enabled, I get:

  BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
  caller is debug_smp_processor_id
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc2+ #2
  Call Trace:
   dump_stack
   check_preemption_disabled
   debug_smp_processor_id
   save_microcode_in_initrd_amd
   ? microcode_init
   save_microcode_in_initrd
   ...

because, well, it says it above, we're using smp_processor_id() in
preemptible code.

But passing the CPU number is not really needed. It is only used to
determine whether we're on the BSP, and, if so, to save the microcode
patch for early loading.

 [ We don't absolutely need to do it on the BSP but we do that
   customarily there. ]

Instead, convert that function parameter to a boolean which denotes
whether the patch should be saved or not, thereby avoiding the use of
smp_processor_id() in preemptible code.

Signed-off-by: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20170528200414.31305-1-bp@alien8.de
Signed-off-by: Ingo Molnar

Tigran has moved

2017-05-12T22:57:15+00:00

Cc: Tigran Aivazian 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86/microcode/AMD: Remove redundant NULL check on mc

2017-03-18T11:31:58+00:00

mc is a pointer to the static u8 array amd_ucode_patch and
therefore can never be null, so the check is redundant. Remove it.

Detected by CoverityScan, CID#1372871 ("Logically Dead Code")

Signed-off-by: Colin Ian King 
Cc: kernel-janitors@vger.kernel.org
Cc: x86-ml 
Link: http://lkml.kernel.org/r/20170315171010.17536-1-colin.king@canonical.com
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner

x86/microcode/AMD: Remove struct cont_desc.eq_id

2017-01-23T09:02:51+00:00

The equivalence ID was needed outside of the container scanning logic
but now, after this has been cleaned up, not anymore. Now, cont_desc.mc
is used to denote whether the container we're looking at has the proper
microcode patch for this CPU or not.

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/20170120202955.4091-17-bp@alien8.de
Signed-off-by: Thomas Gleixner