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]

Date:	Fri, 6 Jan 2012 11:37:34 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	Andi Kleen <andi@...stfloor.org>, 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

> I checked the most recent K8 (Hammer) and Pentium4 documentation,
> and didn't find mention of anything related. So pointing out where you

Sorry don't really plan to do any errata archaeology for this folly.

Maybe it got fixed in the latest versions, I remember them being there
on some early ones at least.

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

The kernel never does >4GB copies, memsets, so it's not buggy.
It's just like any other obscure errata that doesn't matter because
it's not exercised.

REP_GOOD just means "string instructions are faster for 4K operations"

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

Modern kernels are bootmem less.

> 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).

I bet there are more "int"s in the allocators and other code. It would
surprise me if it worked even with a changed memset.

Besides it obviously would be a bad idea on non preemptive kernels,
and since that can always happen it would be bad code, hopefully
never hitting any trees.

If you need it in Xen please just add the cmps there.

-Andi
-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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/