linux-kernel - Re: Linux 3.18.2 / xen 4.4.1 dom0

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150122175818.GB3554@pd.tnic>
Date:	Thu, 22 Jan 2015 18:58:18 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	James Dingwall <james@...gwall.me.uk>
Cc:	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Linux 3.18.2 / xen 4.4.1 dom0 - microcode oops

On Thu, Jan 22, 2015 at 05:43:15PM +0000, James Dingwall wrote:
> This patch solves it for me on my dom0 with 3.18.3, now there is
> nothing printed at all from the microcode driver which doesn't seem
> surprising given where the return is.

Yap, xen does/will update microcode differently...

> I'll check it on bare metal at the next opportunity but from my
> understanding of what is happening there I don't see that it should
> have any impact at all.

Yeah, it shouldn't have any effect on baremetal in the sense that it
should load properly there. And it is a fix for baremetal too, as Boris
pointed out.

I'm still curious as to why does it say this on your machine:

[  176.855832] microcode: CPU0 sig=0x10676, pf=0x1, revision=0x60c
[  176.855844] microcode: CPU0 update to revision 0x60f failed

?

This basically says that we do try to update with the patch but the
hardware doesn't accept it.

Is this new? Did it ever update microcode properly?

Where do you get the microcode for that machine?

Can you run the scriptlet below as root and send me the results? You'd
need the msr-tools package and the msr.ko kernel module loaded. Ask if
you need help.

Also, please send me a full dmesg with "ignore_loglevel log_buf_len=16M
debug" on the kernel command line, privately is fine too.

Thanks.

--
#!/bin/bash

echo "/proc/cpuinfo: "
cat /proc/cpuinfo

echo; echo "dmesg: "
dmesg | grep -i microcode
modprobe msr 2>/dev/null

echo ; echo "MSRs: (0x8b) "
rdmsr --all 0x8b
--

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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/