linux-kernel - Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode output messages

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:	Fri, 6 Nov 2009 20:46:26 +0100
From:	Andreas Herrmann <herrmann.der.user@...glemail.com>
To:	Dmitry Adamushko <dmitry.adamushko@...il.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>, Mike Travis <travis@....com>,
	Tigran Aivazian <tigran@...azian.fsnet.co.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <borislav.petkov@....com>,
	Andreas Mohr <andi@...as.de>, Jack Steiner <steiner@....com>
Subject: Re: [ RFC, PATCH - 1/2, v2 ] x86-microcode: refactor microcode
 output messages

On Fri, Nov 06, 2009 at 01:56:31PM +0100, Dmitry Adamushko wrote:
> 2009/11/6 Andreas Herrmann <herrmann.der.user@...glemail.com>:

   <snip>

> >> (CPU3 belongs to both sets) unless summarize_cpu_info() is utterly
> >> broken.
> >
> > I didn't check that yet.
> 
> Yeah, this behavior is likely due to a missing cpumask_clear() in
> summarize_cpu_info().

Yeah, that fixes the wrong messages.
The other problem of not-updated CPU microcode after suspend/resume persists.

> should be as follows:
> 
>       if (!alloc_cpumask_var(&cpulist, GFP_KERNEL))
>               return;
> 
> +    cpumask_clear(cpulist);

Better use zalloc_cpumask instead of alloc/clear.

> >> sure, my test is somewhat limited... anyway, first of all I'd like to
> >> get a clear understanding of your logs. Thanks for yout test btw. :-))
> >
> > I'll send you full logs asap.
> 
> Thanks. Maybe it's something about a particular sequence of actions
> that triggers this behavior. Or was it reproducible with the very
> first pm-suspend invocation after "modprobe microcode.ko"?

The sequence is:

1. loading microcode.ko
2. setting cpu2 offline
3. setting cpu2 online
4. suspend (pm-suspend)
5. resume

microcode of CPU2 is not updated:

  # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done
  PATCH_LEVEL          = 0x0000000001000083
  PATCH_LEVEL          = 0x0000000001000083
  PATCH_LEVEL          = 0x0000000001000065
  PATCH_LEVEL          = 0x0000000001000083

dmesg attached.

As I've said, that test used to pass with all CPUs updated to new
ucode in the past (at least that I think so ;-( -- but in contrast to
my previous mail this doesn't seem to be related to your patch. I
tested latest mainline and the test fails as well ... seems that I
need to do some debugging.


Regards,
Andreas

PS1: You should remove the needless newline from the patch level string:

 static int version_snprintf(char *buf, int len, struct cpu_signature *csig)
 {
-	return snprintf(buf, len, "patch_level=0x%x\n", csig->rev);
+	return snprintf(buf, len, "patch_level=0x%x", csig->rev);
 }
 
PS2: I plan to remove further needless messages from the amd ucode driver asap.

View attachment "dmesg-dimm" of type "text/plain" (40976 bytes)