Unaligned data on ARM architectures do not perform efficiently unaligned
memory access, and in the case of ARMv7 and iOS it completely breaks. The OCB
algorithm dereferences a uint64x2_t pointer, and is replaced by a
memcpy to avoid penalties when trying to align it.
More info https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/knowledgebase/docs/kb95.html
This refactors out a very common pattern of formatting "%s: %s" with
e.function.c_str() and strerror( e.the_errno ) into just the what()
method of NetworkException. It's also a prerequisite for making cleaner
public API for any exceptions we throw, and allows us to more easily
get exceptions passed back to us to handle.
Fixes following problem when compiling mosh with gcc4.8 and
__ARM_NEON__ defined by using -121 instead of 135.
ocb.cc: In function 'block double_block(block)':
ocb.cc:263:56: error: narrowing conversion of '135' from
'int' to '__builtin_neon_qi' inside { } is ill-formed in
C++11 [-Werror=narrowing]
Signed-off-by: Pasi Sjöholm <pasi.sjoholm@jollamobile.com>
Instead of looking for htobe64 which is be available both when
be64toh or betoh64 are, check for the latter functions. If we
find betoh64 but not be64toh, use compat #defines. If both
can't be found, search for OSX' OSSwapHostToBigInt64.
Also include sys/types.h in byteorder.h (which is necessary for
byteorder functions on OpenBSD), and incidentally fixes build
of networkfragment.cc.
Fixes build on OpenBSD
Signed-off-by: Jérémie Courrèges-Anglas <jca@wxcvbn.org>
This test doesn't return an error on failure and also was triggering a
stack protector warning on some platforms. We have an end-to-end test of
OCB in src/tests/ocb-aes.cc that seems to work well.
... plus the local changes from:
3b2604b Handle early gcc compilers that are missing __builtin_bswap64 or __builtin_ctz
e8236c5 Use AlignedBuffer stedda posix_memalign(). Should work on PPC OS X 10.5.
9827d12 Switch to OpenSSL AES
EL5 lacks htobe64 and friends. Using its byteswap.h requires an endianness
check in our headers, which is fragile and compiler-dependent. It's a fair
amount of code [1], and is only useful on EL5.
So instead, let's include a fallback implementation of these functions, and use
it whenever we can't find the (now-)standard Linux or OS X routines. The
fallback is endianness-independent and should work on any platform.
[1] https://github.com/rurban/mosh/commit/da1a5abd1e09f0c1e9295357bb480a643d9dc8e3
clang was spewing warnings about the unrecognized -fno-default-inline. (Oddly,
it warns only with -c, not when compiling directly to an executable.) For
completeness we also check -pipe, even though clang is OK with that one.
It should be fine to omit either flag. gcc -fno-default-inline drops the
implicit 'inline' annotation on functions defined inside a class scope, but
'inline' is only a hint anyway. -fno-default-inline does not change linkage.
-pipe is merely a compile speed optimization.
This tests cryptographic primitives implemented by others. It uses the same
interfaces and indeed the same compiled object code as the Mosh client and
server. It does not particularly test any code written for the Mosh project.
Instead of guessing the right function to use, we malloc() 15 bytes more than
we need, and compute the aligned offset within. The AlignedBuffer class takes
care of passing the original pointer to free().
This simplifies the core crypto routines, especially the error handling. In
fact there was already one error path where we were failing to call free().
John Hood