linux-kernel - Re: [GIT PULL, v2] x86/microcode tree changes for v3.19

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]

Date:	Thu, 11 Dec 2014 10:12:38 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>
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
fine.

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.

-- 
Regards/Gruss,
    Boris.

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