linux-kernel - Re: [PATCH] x86: Fix AMD K6 indirect call check v2

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:	Sun, 21 Apr 2013 19:44:56 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] x86: Fix AMD K6 indirect call check v2

On Sun, Apr 21, 2013 at 10:06:58AM -0700, H. Peter Anvin wrote:
> On 04/21/2013 09:49 AM, Andi Kleen wrote:
> > From: Andi Kleen <ak@...ux.intel.com>
> > 
> > The AMD K6 errata check relies on timing a indirect call.
> > But the way it was written it could be optimized to a direct call.
> > Force gcc to actually do a indirect call and not just
> > constant resolve the target address.
> > 
> > Found during code review, no runtime testing due to lack
> > of hardware.
> 
> Maybe it would be even better to just code the indirect call instruction
> in assembly?
> 
> Something like:
> 
> 	asm volatile("call *%0"
> 		     : : "r" (vide)
> 		     : "eax", "ecx", "edx");
> 
> Gotta love the metal mask(?) fix without bumping the stepping number...

They fixed it in the next revision:

"Resolution Status. This erratum is corrected in the C stepping of the
AMD-K6 processor."

On page 12 here http://www.datasheetcatalog.org/datasheet/AdvancedMicroDevices/mXwsxv.pdf

But it looks some revBs got fixed too reportedly: "... before B
9730xxxx...". Who knows.

Btw, I can't help but cringe everytime I see the wording "...
instruction is speculatively executed... " in an erratum :-).

So the poor K6 had some issues with SMC, that's sad.

But I have hard time understanding what that test with the 10^6 loop
iterations is supposed to achieve. And what makes sure that the RDTSCs
don't get reordered? Or maybe K6 wasn't reordering that aggressively...

Erratum says "unpredictable system behavior" but it seems it wasn't that
unpredictable after all - otherwise the fix would've been "HLT" right
then and there. :)

Oh well.

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