linux-kernel - Re: [PATCH v5] x86: Enable fast strings on Intel if BIOS hasn't already

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:	Wed, 1 May 2013 12:34:04 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Andy Lutomirski <luto@...capital.net>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	Andrew Lutomirski <luto@....edu>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v5] x86: Enable fast strings on Intel if BIOS hasn't
 already

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