On Sun, Jul 06, 2014 at 10:25:19AM +0200, Andy Polyakov via RT wrote:
> > Running `make test` with Clang sanitizers results in some issues with
> > unaligned pointers surrounding some uses of buffers cast to a size_t*.
> > The sanitizers used were `-fsanitize=undefined -fsanitize=address`.
>
> Those are conscious choices based on the fact that some CPUs, x86_64
> included, are perfectly capable of tolerating unaligned access, in sense
> that code doesn't crash and produces correct result. In other words,
> it's legitimate platform-specific behaviour. As a compromise it's
> possible to arrange it so that build doesn't attempt to utilize this
> platform capability *if* compiled with -DPEDANTIC. Would it be
> acceptable compromise?
It already seems to be controlled by the STRICT_ALIGNMENT define,
which looks like:
#define STRICT_ALIGNMENT 1
#if defined(__i386) || defined(__i386__) || \
defined(__x86_64) || defined(__x86_64__) || \
defined(_M_IX86) || defined(_M_AMD64) || defined(_M_X64) || \
defined(__aarch64__) || \
defined(__s390__) || defined(__s390x__)
# undef STRICT_ALIGNMENT
#endif
This are the result I get without the strict alignment:
without EVP (and AES-NI):
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 109991.09k 121907.05k 124370.43k 125518.43k 125509.63k
With EVP:
aes-128-cbc 659929.40k 717046.56k 726172.76k 731055.52k 732257.95k
And with strict alignment:
without EVP:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128 cbc 111016.13k 121922.45k 124197.29k 125595.48k 125438.63k
With EVP:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 655557.30k 714415.45k 726278.83k 730977.09k 731893.55k
I would have no problem with strict alignment being the default
when looking at that.
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
