This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Optimize SSE 4.1 x86_64 memcmp
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, OndÅej BÃlka <neleai at seznam dot cz>
- Date: Mon, 3 Feb 2014 18:15:54 +0000
- Subject: Re: [PATCH] Optimize SSE 4.1 x86_64 memcmp
- Authentication-results: sourceware.org; auth=none
- References: <52EBBCC2 dot 7090807 at redhat dot com> <52EBC480 dot 4000509 at redhat dot com> <52EF6E9E dot 8050708 at redhat dot com>
On Mon, 3 Feb 2014, Florian Weimer wrote:
> One thing I would like to get consensus on eventually is whether future
> implementations of memcmp must not behave as a timing oracle. (There might be
I don't understand what your proposed requirement is - I certainly expect
memcmp to be faster for differences in the first byte than for differences
at the millionth byte, for example. Are you saying that if the difference
is in a given aligned 8-byte block then the timing shouldn't indicate
where in that block the difference is, or something like that?
I don't believe specific timing properties are part of the expected
interface to memcmp.
> architectures where achieving this has a run-time cost.) If we are unwilling
> to make this promise, the oracle-free version would have to be conditional on
> _FORTIFY_SOURCE.
I don't think this is anything to do with _FORTIFY_SOURCE, which is about
detecting some uses of functions that involve undefined behavior at C
level, and bounding the effects of that undefined behavior by terminating
the program. It sounds to me more like a separate function at the C API
level, much like memset_s in C11 Annex K (memset required not to be
optimized away, for clearing memory that may contain sensitive data).
--
Joseph S. Myers
joseph@codesourcery.com