public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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