From: Borislav Petkov <bp@alien8.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andi Kleen <andi@firstfloor.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] x86: Fix AMD K6 indirect call check v2
Date: Sun, 21 Apr 2013 19:44:56 +0200 [thread overview]
Message-ID: <20130421174456.GA4559@pd.tnic> (raw)
In-Reply-To: <51741CB2.3090209@zytor.com>
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@linux.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.
--
next prev parent reply other threads:[~2013-04-21 17:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-21 16:49 [PATCH] x86: Fix AMD K6 indirect call check v2 Andi Kleen
2013-04-21 17:06 ` H. Peter Anvin
2013-04-21 17:13 ` Andi Kleen
2013-04-21 17:44 ` Borislav Petkov [this message]
2013-04-21 22:35 ` H. Peter Anvin
2013-04-21 22:48 ` Borislav Petkov
2013-04-22 11:25 ` Wolfram Gloger
2013-04-22 12:58 ` Ondrej Zary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130421174456.GA4559@pd.tnic \
--to=bp@alien8.de \
--cc=ak@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox