lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 24 Feb 2015 11:37:12 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	X86 ML <x86@...nel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Quentin Casasnovas <quentin.casasnovas@...cle.com>
Subject: [PATCH 13/13] x86/microcode/intel: Fix printing of microcode blobs in show_saved_mc()

From: Borislav Petkov <bp@...e.de>

When doing

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

in order to reload microcode, I get:

  microcode: Total microcode saved: 1
  BUG: using smp_processor_id() in preemptible [00000000] code: bash/2606
  caller is debug_smp_processor_id+0x17/0x20
  CPU: 1 PID: 2606 Comm: bash Not tainted 3.19.0-rc7+ #9
  Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012
   ffffffff81a4266d ffff8802131db808 ffffffff81666588 0000000000000007
   0000000000000001 ffff8802131db838 ffffffff812e6eef ffff8802131db868
   00000000000306a9 0000000000000010 0000000000000015 ffff8802131db848
  Call Trace:
   dump_stack
   check_preemption_disabled
   debug_smp_processor_id
   show_saved_mc
   ? save_microcode.constprop.8
   save_mc_for_early
   ? print_context_stack
   ? dump_trace
   ? __bfs
   ? mark_held_locks
   ? get_page_from_freelist
   ? trace_hardirqs_on_caller
   ? trace_hardirqs_on
   ? __alloc_pages_nodemask
   ? __get_vm_area_node
   ? map_vm_area
   ? __vmalloc_node_range
   ? generic_load_microcode
   generic_load_microcode
   ? microcode_fini_cpu
   request_microcode_fw
   reload_store
   dev_attr_store
   sysfs_kf_write
   kernfs_fop_write
   vfs_write
   ? sysret_check
   SyS_write
   system_call_fastpath
  microcode: CPU1: sig=0x306a9, pf=0x10, rev=0x15
  microcode: mc_saved[0]: sig=0x306a9, pf=0x12, rev=0x1b, toal size=0x3000, date = 2014-05-29

because we're using smp_processor_id() in preemtible context. And we
don't really need to use it there because the microcode container we're
dumping is global and CPU-specific info is irrelevant.

While at it, make pr_* stuff use "microcode: " prefix for easier
grepping and document how to enable the DEBUG build.

Signed-off-by: Borislav Petkov <bp@...e.de>
---
 arch/x86/kernel/cpu/microcode/intel_early.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/intel_early.c b/arch/x86/kernel/cpu/microcode/intel_early.c
index 2fa9ad39e0e5..079d8d41fba3 100644
--- a/arch/x86/kernel/cpu/microcode/intel_early.c
+++ b/arch/x86/kernel/cpu/microcode/intel_early.c
@@ -16,6 +16,14 @@
  *	as published by the Free Software Foundation; either version
  *	2 of the License, or (at your option) any later version.
  */
+
+/*
+ * This needs to be before all headers so that pr_debug in printk.h doesn't turn
+ * printk calls into no_printk().
+ *
+ *#define DEBUG
+ */
+
 #include <linux/module.h>
 #include <linux/mm.h>
 #include <linux/slab.h>
@@ -28,6 +36,9 @@
 #include <asm/tlbflush.h>
 #include <asm/setup.h>
 
+#undef pr_fmt
+#define pr_fmt(fmt)	"microcode: " fmt
+
 static unsigned long mc_saved_in_initrd[MAX_UCODE_COUNT];
 static struct mc_saved_data {
 	unsigned int mc_saved_count;
@@ -398,8 +409,7 @@ static void __ref show_saved_mc(void)
 	sig = uci.cpu_sig.sig;
 	pf = uci.cpu_sig.pf;
 	rev = uci.cpu_sig.rev;
-	pr_debug("CPU%d: sig=0x%x, pf=0x%x, rev=0x%x\n",
-		 smp_processor_id(), sig, pf, rev);
+	pr_debug("CPU: sig=0x%x, pf=0x%x, rev=0x%x\n", sig, pf, rev);
 
 	for (i = 0; i < mc_saved_data.mc_saved_count; i++) {
 		struct microcode_header_intel *mc_saved_header;
-- 
2.2.0.33.gc18b867

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ