aboutsummaryrefslogtreecommitdiff
path: root/src/test/test_hs_intropoint.c
diff options
context:
space:
mode:
authorMicah Elizabeth Scott <beth@torproject.org>2023-05-16 16:28:26 -0700
committerDavid Goulet <dgoulet@torproject.org>2023-05-24 11:43:11 -0400
commit23f4a28f9755a228ab295d5358298f1a72f8aff1 (patch)
treeb6ab276b75d9ee5bd8ce693d6f1162ef4a66fe92 /src/test/test_hs_intropoint.c
parenta3ff3155c22e7cf093667c6c32166a8f9c77a79a (diff)
downloadtor-23f4a28f9755a228ab295d5358298f1a72f8aff1.tar.gz
tor-23f4a28f9755a228ab295d5358298f1a72f8aff1.zip
token_bucket_ctr: replace 32-bit wallclock time with monotime
This started as a response to ticket #40792 where Coverity is complaining about a potential year 2038 bug where we cast time_t from approx_time() to uint32_t for use in token_bucket_ctr. There was a larger can of worms though, since token_bucket really doesn't want to be using wallclock time here. I audited the call sites for approx_time() and changed any that used a 32-bit cast or made inappropriate use of wallclock time. Things like certificate lifetime, consensus intervals, etc. need wallclock time. Measurements of rates over time, however, are better served with a monotonic timer that does not try and sync with wallclock ever. Looking closer at token_bucket, its design is a bit odd because it was initially intended for use with tick units but later forked into token_bucket_rw which uses ticks to count bytes per second, and token_bucket_ctr which uses seconds to count slower events. The rates represented by either token bucket can't be lower than 1 per second, so the slower timer in 'ctr' is necessary to represent the slower rates of things like connections or introduction packets or rendezvous attempts. I considered modifying token_bucket to use 64-bit timestamps overall instead of 32-bit, but that seemed like an unnecessarily invasive change that would grant some peace of mind but probably not help much. I was more interested in removing the dependency on wallclock time. The token_bucket_rw timer already uses monotonic time. This patch converts token_bucket_ctr to use monotonic time as well. It introduces a new monotime_coarse_absolute_sec(), which is currently the same as nsec divided by a billion but could be optimized easily if we ever need to. This patch also might fix a rollover bug.. I haven't tested this extensively but I don't think the previous version of the rollover code on either token bucket was correct, and I would expect it to get stuck after the first rollover. Signed-off-by: Micah Elizabeth Scott <beth@torproject.org>
Diffstat (limited to 'src/test/test_hs_intropoint.c')
-rw-r--r--src/test/test_hs_intropoint.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/src/test/test_hs_intropoint.c b/src/test/test_hs_intropoint.c
index cbcdeade92..82b7ec029d 100644
--- a/src/test/test_hs_intropoint.c
+++ b/src/test/test_hs_intropoint.c
@@ -14,6 +14,7 @@
#include "test/test.h"
#include "test/log_test_helpers.h"
#include "lib/crypt_ops/crypto_rand.h"
+#include "lib/time/compat_time.h"
#include "core/or/or.h"
#include "core/or/channel.h"
@@ -127,7 +128,7 @@ helper_create_intro_circuit(void)
tt_assert(circ);
circuit_change_purpose(TO_CIRCUIT(circ), CIRCUIT_PURPOSE_OR);
token_bucket_ctr_init(&circ->introduce2_bucket, 100, 100,
- (uint32_t) approx_time());
+ (uint32_t) monotime_coarse_absolute_sec());
done:
return circ;
}