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  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]
Date:	Thu, 11 Dec 2014 10:12:38 +0100
From:	Borislav Petkov <>
To:	Ingo Molnar <>
Cc:	Linus Torvalds <>,
	Linux Kernel Mailing List <>,
	Thomas Gleixner <>,
	"H. Peter Anvin" <>,
	Andrew Morton <>
Subject: Re: [GIT PULL, v2] x86/microcode tree changes for v3.19

On Thu, Dec 11, 2014 at 07:25:08AM +0100, Ingo Molnar wrote:
> > Hmm. There's a conflict with commit 02ecc41abcea ("x86, 
> > microcode: Limit the microcode reloading to 64-bit for now"), 
> Sorry, should have mentioned that explicitly, but forgot about 
> it.
> > but I'm going to assume that the issue is fixed now, and that 
> > commit fbae4ba8c4a3 ("x86, microcode: Reload microcode on 
> > resume") that causes the conflict also handles the 32-bit case 
> > correctly. So my merge is going to just remove the X86_64 test, 
> > effectively undoing that first commit, ratehr than keep it 
> > around.

Yes, this is the intended outcome.

> > If it turns out that the 64-bit limitation needs to be still in 
> > place, holler. We can re-do the ugly 64-bit limit thing if 
> > required.
> Hm, so in my own conflict resolution I kept that check, last I 
> heard Boris was still seeing weirdnesses (read: crashes) on 
> 32-bit and I'm not sure even the full series fixes it all.
> In any case, would be nice to double check this and reinstate the 
> limitation explicitly if it's still needed, or apply a fix. 
> Boris?

The problem was that while I was testing 32-bit on an IVB laptop, the
machine would triple-fault on resuming from disk. Sometimes, not on each
resume cycle. So I thought this was originally caused by the changes to
the early reloading mechanism.

However, I did a coarse bisection all the way back to 3.10 and the issue
still exists. So it either is this particular laptop or 32-bit suspend
from disk has been always broken.

In any case, the current mainline state of the microcode loader should
be the correct one, I've been testing it on AMD and Intel, both early
and/xor late microcode loader, suspend to disk and to ram and all works

stable@ would need addressing at some point but I'd like to leave it in
mainline a bit to see some more testing and backport it to stable when
there's more confidence all is ok.

Thanks guys.


Sent from a fat crate under my desk. Formatting is fine.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists