Misaligned buffers come from the null method, as it uses a 1-byte header
rather than (16*n+8)-byte like all other methods. When such a buffer enters
the transmit path again through fastd's forward feature, it will violate
the fastd_block128_t alignment (when there are other sessions that do
not use the null method).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Consider the optimized x86 implementations before the generic ones, so
the optimized versions can actually get selected.
Fixes: c095ce9b4d ("build: switch to Meson build system")
The variable gains an additional meaning: In addition to the tailroom
needed in the source buffer for decryption, is also refers to the
tailroom in the destination buffer for encryption.
With a very small MTU and a great number of configured methods, the
receive buffer may be too small for a handshake packet. Always allocate
receive buffers of at least 1232 bytes, even with smaller MTU.
We also check that we never allocate a buffer for a bigger handshakes
and abort otherwise. This could be turned into a soft error in the
future, but so far we have a nice marging until we hit that number
(maximum handshake with all methods is ~640 bytes).
uhash needs the input padded to a multiple of 32 bytes, with the special
case that an empty input needs to be padded to 32 as well. Handle this
special case in the uhash code itself, so it doesn't need to be handled
by the callers.
This fixes an uninitialized memory error reported by valgrind for the
method aes128+ctr. It is unclear why only this method is affected, or why
it is even necessary at all - we only support stream cipher, and
crypto_onetimeauth_poly1305_verify does not care about padding.
With the update to OpenSSL 1.1, only the aes128-ctr cipher references
symbols from the library, so we can remove it from the toplevel
target_link_libraries() and build.h.