As the cleanup function reads from the correct address on the parent frame,
it is currently unclear why AddressSanitizer complains about that pointer
dereference.
The vici logger uses the listener_t.log() callback to raise vici events.
When doing so, it holds the bus lock as reader while acquiring the vici socket
mutex (1). If at the same time the vici socket enables a writer, that thread
tries to lock the watcher mutex (2). The watcher thread uses debugging while
holding the lock, i.e. acquires the bus read lock (3).
(1) bus.rlock -> vici.lock!
(2) vici.lock -> watcher.lock!
(3) watcher.lock -> bus.rlock!
This all actually would resolve just fine, as we have a shared read lock on the
bus. However, under Windows we seem to have a strict writer preference when
acquiring the rwlock (4). This results in blocking read locks until any pending
write lock can be fulfilled, and makes the constellation deadlock. The relevant
threads are:
Thread (1)
6 0x71313d25 in wait_ at threading/windows/mutex.c:137
7 0x7054c8a2 in find_entry at vici_socket.c:201
8 0x7054d690 in send_ at vici_socket.c:624
9 0x7054f6c1 in send_op at vici_dispatcher.c:119
10 0x705502c1 in raise_event at vici_dispatcher.c:469
12 0x704c3878 in log_cb at bus/bus.c:332
13 0x712c7c3a in invoke_function at collections/linked_list.c:414
14 0x704c3a63 in vlog at bus/bus.c:400
15 0x704c3b36 in log_ at bus/bus.c:430
18 0x70508f1f in process_response at sa/ikev2/task_manager_v2.c:664
20 0x704f5430 in process_message at sa/ike_sa.c:1369
21 0x704e3823 in execute at processing/jobs/process_message_job.c:74
22 0x712e629f in process_job at processing/processor.c:235
Thread (2)
4 0x71313b61 in lock at threading/windows/mutex.c:66
5 0x712e81fd in add at processing/watcher.c:441
6 0x712e1ab9 in add_watcher at networking/streams/stream.c:213
7 0x712e1b4d in on_write at networking/streams/stream.c:237
8 0x7054d606 in _cb_enable_writer at vici_socket.c:609
9 0x712e5e34 in execute at processing/jobs/callback_job.c:77
10 0x712e629f in process_job at processing/processor.c:235
Thread (3)
3 0x71313f38 in read_lock at threading/windows/rwlock.c:74
4 0x704c3971 in vlog at bus/bus.c:373
5 0x704cc156 in dbg_bus at daemon.c:126
6 0x712e7bf9 in watch at processing/watcher.c:316
7 0x712e5e34 in execute at processing/jobs/callback_job.c:77
8 0x712e629f in process_job at processing/processor.c:235
Thread (4)
3 0x71313f70 in write_lock at threading/windows/rwlock.c:82
4 0x704c378b in remove_logger at bus/bus.c:290
5 0x704cb284 in listener_unregister at control/controller.c:166
6 0x713136cd in thread_cleanup_pop at threading/windows/thread.c:558
8 0x704cb94e in initiate at control/controller.c:435
9 0x70553996 in _cb_initiate at vici_control.c:187
12 0x7054d200 in _cb_process_queue at vici_socket.c:508
13 0x712e5e34 in execute at processing/jobs/callback_job.c:77
14 0x712e629f in process_job at processing/processor.c:235
To avoid such a situation, we dissolve the (1) lock sequence. It's actually
never good practice to acquire shared locks during bus hooks, as it is
problematic if we raise bus events while holding the lock. We do so by
raising vici events for log message asynchronously, but of curse must keep
log order as is using a synchronized queue.
This allows us to do modifications to the kernel tree and rebuild that kernel
using make-testing. We can even have a git kernel tree in a directory to
do kernel development.
By using a derived key r^2 we can improve performance, as we can do loop
unrolling and slightly better utilize SIMD instructions.
Overall ChaCha20-Poly1305 performance increases by ~12%.
Converting integers to/from our 5-word representation in SSE does not seem
to pay off, so we work on individual words.
We always build the driver on x86/x64, but enable it only if SSSE3 support
is detected during runtime.
Poly1305 uses parallel 32-bit multiplication operands yielding a 64-bit result,
for which two can be done in parallel in SSE. This is minimally faster than
multiplication with 64-bit operands, and also works on 32-bit builds not having
a __int128 result type.
On a 32-bit architecture, this is more than twice as fast as the portable
driver, and on 64-bit it is ~30% faster.
Global reqid allocation (94eb09ac) broke fixed reqid allocation. Resupport them
by bypassing allocation in the kernel if a fixed reqid has been configured.
Fixes#976.
We use the message ID and fragment number as IV generator. As IKEv2 uses
distinct message ID counters for actively and passively initiated exchanges,
each IV would be used twice. As we explicitly reject such message IDs since
d0ed1079, original-responder initiated exchanges fail with counter mode ciphers.
This commit separates IV space in two halves for sequential IVs, and
automatically assigns once reused sequence numbers to the second half.
Fixes#980.
When using a cipher with sequential IVs, we never must pass an identical IV
to the IV generator. To avoid it when using IKEv2 fragmentation, use the lower
bits of the 64-bit message ID as the fragment number.
While the server signs the ephemeral DH parameters, it can be tricked to its
lowest supported DH group by a man-in-the-middle:
https://weakdh.org/imperfect-forward-secrecy.pdf
While we at least use 2048-bit DH groups as server, the client accepts any
DH prime the server sends. If it supports export ciphers, only a 512-bit prime
may be used.
As TLS does not define nor negotiate a DH group for cipher suites, the client
actually must accept what the server offers. To avoid downgrades to weak
DH groups, we must reject what we consider insecure. We set this limit to
1024-bit primes. While this breaks compatibility with TLS servers using weaker
primes, this is what we expect servers at least use. Most browser vendors use
the same limit in a similar fix.
As we now pass the vici connection to the command dispatcher callback, we can't
parse the --uri option to create the connection from the same callback. Instead
pre-process the common command options in a separate loop, and ignore the same
options while processing the actual command.
Split up the almighty utils.[ch] to separate files in the utils/utils subfolder.
These are not meant to include manually, but bring back some order to all
this functionality included through utils.h.
Additionally give some love to apidoc generation.
We don't actually define a vector, but only prototype the test vector
implemented in a different file. GCC uses the correct symbol during testing,
but clang correctly complains about duplicated symbols during linking.
We see any plugin startup messages during suite configuration, where
initialization is called once to query plugin features. No need to be verbose
and show these messages once again in the first test.
This allows us to show which transform from which plugin failed. Also, we use
the new cleanup handler functionality that allows proper deinitialization on
failure or timeout.
If a test fails in a timeout or a test failure, longjmp() is used to restore
the thread context and handle test failure. However, there might be unreleased
resources, namely locks, which prevent the library to clean up properly after
finishing the test.
By using thread cleanup handlers, we can release any test subject internal or
test specific external resources on test failure. We do so by calling all
registered cleanup handlers.
The libgcrypt RNG implementation uses static buffer allocation which it does
not free. There is no symbol we can catch in leak-detective, hence we explicitly
initialize the RNG during the whitelisted gcrypt_plugin_create() function.
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.
Martin Willi