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

On Wed, May 1, 2013 at 9:42 AM, H. Peter Anvin <hpa@...or.com> wrote:
> On 05/01/2013 09:34 AM, Theodore Ts'o wrote:
>>
>> 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....
>>
>
> The erratum reads seriously, but it only affects crossings between pages
> of different page types, which is rare in itself.  WT and WP are not
> even used in Linux; the UC case we end up doing 8-byte stores instead of
> the proper size, which is wrong, but for the case where the user is
> malicious the user could just do that directly, and it seems extremely
> hard to envision a scenario where someone would do that intentionally.

(Just my luck.  I'm currently trying to implement WT via PAT by
stealing a slot from either UC or UC-.)

There's already a warning in the Intel system programming manual:

11.5.2.3
Writing Values Across Pages with Different Memory Types
If two adjoining pages in memory have different memory types, and a
word or longer
operand is written to a memory location that crosses the page boundary between
those two pages, the operand might be written to memory twice. This
action does not
present a problem for writes to actual memory; however, if a device is
mapped the
memory space assigned to the pages, the device might malfunction.

Is there any code that memcpys across memory types and expects any
particularly sensible behavior out of it?

I'll try to see what Windows is doing.  From my cursory reading of the
errata documents, this affects basically all CPUs -- it doesn't seem
to have been fixed in any revision of anything.  So this erratum
doesn't seem to explain why different BIOSes would do different
things.

--Andy

P.S. The printk is in the right place in the patch, but the text is
misleading.  I'll fix it if there's a v6.

>
>         -hpa
>

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/