gcry_check_version() does not free statically allocated resources. However,
we can't whitelist it in some versions, as it is not a resolvable symbol name.
Instead, whitelist our own plugin constructor function.
While we could use posix_memalign(3), that is not fully portable. Further, it
might be difficult on some platforms to properly catch it in leak-detective,
which results in invalid free()s when releasing such memory.
We instead use a simple wrapper, which allocates larger data, and saves the
padding size in the allocated header. This requires that memory is released
using a dedicated function.
To reduce the risk of invalid free() when working on corrupted data, we fill up
all the padding with the padding length, and verify it during free_align().
While they usually are not included in a normal strongSwan build, the XPC
header indirectly defines these Mach types. To build charon-xpc, which uses
both XPC and strongSwan includes, we have to redefine these types.
To make accept/recvmsg cancelable, we wrap them with poll. As poll itself
does not honor pending cancellations when entering the function, we use our
variant that checks for pending cancellation requests before entering poll().
fstat() in newer MinGWs is defined as non-static inline. With our new static
inline memset()/memcpy() overloads, this raises a warning. To avoid it,
explicitly include <sys/stat.h> once before defining these overloads.
These wrappers guarantee that calls to these functions are noops if the
number of bytes is 0, as calling them with NULL pointers is undefined
according to the C standard, even if the number of bytes is 0 (most
implementations probably ignore the pointers anyway in this case, but
lets make sure).
While Winsock provides many Posix compatibility functions, they do not set
errno, but use WSAGetLastError() for error reporting. The wrapped functions
derive an errno from WSAGetLastError() on failure.
Instead of using weak symbols, we use dlsym() on Windows to find an arbitrary
symbol in libtest to detect its linkage. Instead of creating the associated
hashtable in the test runner, we maintain it in libstrongswan, making it
significantly simpler.
Due to the removal of pthread_once, we manually create the seed for
chunk_hash(). With the new testable functions interface, this won't work for
the hashtable initiated using __attribute__((constructor)). Enforce seeding
before creating that hashtable.
This allows us to disable Unix sockets cleanly on Windows. Replaces some
read/write calls with recv/send counterparts, as Winsock does not like
read/writes.
While DbgHelp provides a convenient API to create backtraces, any executable
linking against DbgHelp gets a more than a significant slow down. Further, it
can only lookup global symbols, as it expects PDB files we can't produce with a
MinGW build.
With some core Kernel32.dll functionality, we can capture stack traces much
faster. Together with the optional libbfd, we can print very fine backtraces.
When --enable-bfd-backtraces is used on Windows, a libbfd.dll is required for
the build. Such a DLL can be created from the binutils sources using:
# build binutils with mingw...
# extract archive members from binutils libraries
x86_64-w64-mingw32-ar x $BINUTILS/bfd/.libs/libbfd.a
x86_64-w64-mingw32-ar x $BINUTILS/intl/libintl.a
x86_64-w64-mingw32-ar x $BINUTILS/libiberty/libiberty.a
# create self-contained libbfd.a, with index
x86_64-w64-mingw32-ar qs libbfd.a *.o
# create DLL from static library
x86_64-w64-mingw32-dlltool -e libbfd.o -l libbfd.lib libbfd.a
x86_64-w64-mingw32-gcc -shared libbfd.a libbfd.o -o libbfd.dll
Handling the result for enum_from_name() is difficult, as checking for
negative return values requires a cast if the enum type is unsigned. The new
signature clearly differentiates lookup result from lookup value.
Further, this actually allows to convert real -1 enum values, which could not
be distinguished from "not-found" and the -1 return value.
This also fixes several clang warnings where enums are unsigned.
Using the same mechanism as the METHOD macro, the CALLBACK macro defines
a hybrid function signature. It strictly uses a weak void* for the first
function parameter, in contrast to the dynamic METHOD object "this" type.
This solves a problem with GNAT when compiling charon-tkm as __atomic*
built-ins are only provided in GCC 4.7 and newer.
Currently GNAT 4.6 and GCC 4.7.2 is shipped with Debian wheezy (stable),
as used in the testing environment. So while the configure script correctly
detected the __atomic* built-ins, and defined HAVE_GCC_ATOMIC_OPERATIONS,
this define turned out to be incorrect when charon-tkm was later built
with GNAT.
These are available since GCC 4.7 and will eventually replace the __sync
operations. They support the memory model defined by C++11. For instance,
by using __ATOMIC_RELAXED for some operations on the reference counters we
can avoid memory barriers, which are required by __sync operations (whose
memory model essentially is __ATOMIC_SEQ_CST).
On many architectures it is safe to read the value directly (those
using cache coherency protocols, and with atomic loads for 32-bit
values) but it is not if that's not the case or if we ever decide to
make refcount_t 64-bit (load not atomic on x86).
So make sure the operation is actually atomic and that users do not
have to care about the size of refcount_t.
Because GCC does not adhere to the priorities defined for constructors
when building with --enable-monolithic (not sure if it was just luck
that it worked in non-monolithic mode - anyway, it's not very portable)
function registration would fail because the hashtable would not be
created yet.
A valgrind analysis of libstrongswan revealed an invalid read of 1 in
the function starts_with(). A more thorough analysis proved this to be
true and showed that with a specially crafted config file (e.g. a single
'#'-character not followed by a newline), the parser might even
interpret the random memory contents following the allocated buffer as
part of the configuration file.
The way the parser is designed, it must be able to skip an inserted
'\0' and continue parsing. Since it is not able to skip two '\0'
characters, the 'fix' of allocating two more bytes than the size of the
parsed file and setting them to '\0' seems to be a safe bet.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
dirname(3) may return a pointer to a statically allocated buffer.
So freeing the returned value can result to undefined behavior. This was
noticed on FreeBSD where it caused very strange crashes.
It is also not thread-safe, which will be addressed later.
Is a bit more memory efficient (also due to lazy instantiation) and
lookups for sections with lots of subsections/keys (e.g. charon.plugins) are
faster.
If realloc return a pointer value different from the value to be
reallocated, a double free can occur in this context.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
When acting on files, we can use fstat() to estimate the buffer size. On
non-file FDs, we dynamically increase an allocated buffer.
Additionally we slightly change the function signature to properly handle
zero-length files and add appropriate unit tests.
Martin Willi