From: "Theodore Ts'o" <tytso@mit.edu>
To: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@amacapital.net>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Andrew Lutomirski <luto@mit.edu>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v5] x86: Enable fast strings on Intel if BIOS hasn't already
Date: Wed, 1 May 2013 12:34:04 -0400 [thread overview]
Message-ID: <20130501163404.GA6286@thunk.org> (raw)
In-Reply-To: <20130501113352.GA29571@pd.tnic>
On Wed, May 01, 2013 at 01:33:52PM +0200, Borislav Petkov wrote:
> It could be some fast strings erratum like AAJ6 or BD3 (they have
> different names for what apparently is the same erratum in different
> docs). Simply search for "intel fast strings erratum" and sample the
> first couple of pdfs to get an idea.
This errata does seem pretty scary:
Problem: Under certain conditions as described in the Software
Developers Manual section "Out-of-Order Stores For String
Operations in Pentium 4, Intel Xeon, and P6 Family
Processors" the processor performs REP MOVS or REP STOS as
fast strings. Due to this erratum fast string REP MOVS/REP
STOS instructions that cross page boundaries from WB/WC
memory types to UC/WP/WT memory types, may start using an
incorrect data size or may observe memory ordering
violations.
Implication: Upon crossing the page boundary the following may occur,
dependent on the new page memory type:
* UC the data size of each write will now always be 8
bytes, as opposed to the original data size.
* WP the data size of each write will now always be 8
bytes, as opposed to the original data size and
there may be a memory ordering violation.
* WT there may be a memory ordering violation.
In fact, there is the question of whether we should be checking to see
if the CPU stepping is one of the ones with the bug, and if so, to
have Linux disable fast strings even if the BIOS didn't, instead of
blindly enabling fast strings....
- Ted
next prev parent reply other threads:[~2013-05-01 16:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-01 5:46 [PATCH v5] x86: Enable fast strings on Intel if BIOS hasn't already Andy Lutomirski
2013-05-01 11:15 ` Ingo Molnar
2013-05-01 11:33 ` Borislav Petkov
2013-05-01 16:34 ` Theodore Ts'o [this message]
2013-05-01 16:42 ` H. Peter Anvin
2013-05-01 16:54 ` Andy Lutomirski
2013-05-01 17:35 ` H. Peter Anvin
2013-05-01 17:50 ` Andy Lutomirski
2013-05-01 17:54 ` H. Peter Anvin
2013-05-01 18:18 ` Andy Lutomirski
2013-05-10 8:25 ` Ingo Molnar
2013-05-01 17:20 ` Theodore Ts'o
2013-05-01 17:35 ` H. Peter Anvin
2013-05-01 16:51 ` Andi Kleen
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=20130501163404.GA6286@thunk.org \
--to=tytso@mit.edu \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@mit.edu \
--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