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]

Message-ID: <b647ffbd0911051040r3987f63es1279c87bf349bcf6@mail.gmail.com>
Date:	Thu, 5 Nov 2009 19:40:53 +0100
From:	Dmitry Adamushko <dmitry.adamushko@...il.com>
To:	Andreas Herrmann <herrmann.der.user@...glemail.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

2009/11/5 Andreas Herrmann <herrmann.der.user@...glemail.com>:
> The patches don't properly work here.
>
> (1) For instance I got following log entries when doing
>    suspend/resume, doing CPU offline/online test and reloading the
>    module:

To avoid possible misunderstandings, I'd like to clarify the output below.

>
>  microcode: original microcode versions...
>  microcode: CPU0-3: patch_level=0x1000065

So this is the 1st time you have loaded a module.

>  platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
>  ...
>  microcode: CPU0-1,3: patch_level=0x1000083

before or after loading a module? CPU2 is down, isn't it?

>
>  microcode: CPU2-3: patch_level=0x1000065

same question as above. Here, either CPUs 0 and 1 are down or have a
different version. Both above messages don't make sense taken together
(CPU3 belongs to both sets) unless summarize_cpu_info() is utterly
broken.

>
>  Microcode Update Driver: v2.00 <tigran@...azian.fsnet.co.uk>, Peter Oruba
>
> The patch levels are:
>
>  # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done
>  PATCH_LEVEL          = 0x0000000001000083
>  PATCH_LEVEL          = 0x0000000001000083
>  PATCH_LEVEL          = 0x0000000001000065
>  PATCH_LEVEL          = 0x0000000001000065

this is after your test has been stopped and all the CPUs are up, right?

>
> (2) During suspend/resume the ucode is not updated:
>
>  hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done
>  PATCH_LEVEL          = 0x0000000001000083
>  PATCH_LEVEL          = 0x0000000001000083
>  PATCH_LEVEL          = 0x0000000001000083
>  PATCH_LEVEL          = 0x0000000001000083
>  hadburg linux # pm-suspend
>  hadburg linux # for i in `seq 0 3`; do lsmsr -c $i PATCH_LEVEL; done
>  PATCH_LEVEL          = 0x0000000001000065
>  PATCH_LEVEL          = 0x0000000001000065
>  PATCH_LEVEL          = 0x0000000001000065
>  PATCH_LEVEL          = 0x0000000001000065
>
>
> That used to work w/o your patches. Didn't have time to look why this
> is now failing. You've changed mc_cpu_callback() -- most likely that
> is causing this regression.

Hmm, cpu-event-callbacks seem to be working on my (Intel) setup. I
have enabled pr_debug messages and also did a little trick to allow
ucode of the same version to be loaded (my cpu is of the recent ucode
by itself) and I can see cpu-callback events for both resuming and
cpu-up cases.

(firstly, upgraded with microcode_ctl as I only have a .dat file)

suspend-resume
...
[  584.506371] microcode: CPU1 removed
[  584.516018] microcode: CPU0 updated to revision 0x57, date = 2007-03-15
[  584.597326] microcode: CPU1 updated upon resume
[  584.597562] microcode: CPU1 updated to revision 0x57, date = 2007-03-15
[  584.597565] microcode: CPU1 added
...

and now cpu1 : down -> up

[ 1616.932249] microcode: CPU1 removed
[ 1633.942502] platform microcode: firmware: requesting intel-ucode/06-0f-02
[ 1633.954638] microcode: data file intel-ucode/06-0f-02 load failed
[ 1633.954642] microcode: CPU1 added


as I understand, you don't see " platform microcode: firmware:
requesting intel-ucode" messages upon 'upping' a cpu, do you?


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. :-))


>
>
> Regards,
> Andreas
>


-- Dmitry
--
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/