linux-kernel - Re: x86-64: memset()/memcpy() not fully standards compliant

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]

Message-Id: <4F06D979020000780006AC49@nat.nue.novell.com>
Date:	Fri, 06 Jan 2012 11:22:33 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	<mingo@...e.hu>, <tglx@...utronix.de>,
	<linux-kernel@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: x86-64: memset()/memcpy() not fully standards compliant

>>> On 06.01.12 at 10:49, Andi Kleen <andi@...stfloor.org> wrote:
> On Thu, Jan 05, 2012 at 06:03:23PM -0800, H. Peter Anvin wrote:
>> On 01/05/2012 05:47 PM, Andi Kleen wrote:
>> >>
>> >> Is that still true, and do we even use string instructions still on
>> >> those old CPUs?  Jan's fixes don't introduce any additional delays in
>> >> the non-string-instruction paths.
>> > 
>> > Yes various of the CPUs with bugs used string instructions.
>> > 
>> 
>> Which CPUs are you talking about here?
> 
> This was various iterations of K8 and PSC. Early Meroms may also have
> had issues (not 100% sure).

I checked the most recent K8 (Hammer) and Pentium4 documentation,
and didn't find mention of anything related. So pointing out where you
found something relevant would be helpful. (And yes, as indicated in
my original mail I too seem to recall there being problems in this area,
but upon closer checking yesterday they all turned out unrelated to
this code.)

>> > Both string and non string instructions are used on modern CPUs,
>> > so making any of that slower is not a good idea.
>> > 
>> 
>> Obviously not, but I'm perfectly fine turning REP_GOOD off on old broken
>> CPUs.
> 
> That would be even worse.

How could you allow a CPU fall under REP_GOOD is its rep
implementation is buggy.

> You would slow a critical fast path operation down for something
> that never happens?!?

It does happen, just (so far) not in-tree. It's a latent problem that's
just waiting for someone else to run into. Apart from large bootmem
allocations (where not even the latency of the memory clearing
matters in any way, there's nothing I know of that would prevent
someone from vmalloc()-ing a huge block of memory and then
calling memset() on it (which ought to be tolerable in a preemptable
kernel at least).

Jan

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