shakedown.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A community for live music fans with roots in the jam scene. Shakedown Social is run by a team of volunteers (led by @clifff and @sethadam1) and funded by donations.

Administered by:

Server stats:

264
active users

#swad

0 posts0 participants0 posts today
Felix Palmen :freebsd: :c64:<p>I need help. First the question: On <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a>, with all ports built with <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>, can I somehow use the <a href="https://mastodon.bsd.cafe/tags/clang" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>clang</span></a> <a href="https://mastodon.bsd.cafe/tags/thread" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>thread</span></a> <a href="https://mastodon.bsd.cafe/tags/sanitizer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>sanitizer</span></a> on a binary actually using LibreSSL and get sane output?</p><p>What I now observe debugging <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a>:</p><p>- A version built with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> (from base) doesn't crash. At least I tried very hard, really stressing it with <a href="https://mastodon.bsd.cafe/tags/jmeter" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>jmeter</span></a>, to no avail. Built with LibreSSL, it does crash.<br>- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM<br>- The thread sanitizer finds nothing to complain when built with OpenSSL<br>- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)<br>- It even complains when running with a single-thread event loop.<br>- I use a single SSL_CTX per listening socket, creating SSL objects from it per connection ... also with multithreading; according to a few sources, this should be supported and safe.<br>- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless<br>- I *could* imagine sharing the SSL_CTX with multiple threads to create their SSL objects from *might* not be safe with LibreSSL, but no idea how to verify as long as the thread sanitizer gives me "delusional" output 😳</p>
Felix Palmen :freebsd: :c64:<p>More interesting progress trying to make <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> suitable for very busy sites!</p><p>I realized that <a href="https://mastodon.bsd.cafe/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> (both with <a href="https://mastodon.bsd.cafe/tags/OpenSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenSSL</span></a> and <a href="https://mastodon.bsd.cafe/tags/LibreSSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LibreSSL</span></a>) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a <a href="https://mastodon.bsd.cafe/tags/lockfree" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>lockfree</span></a> queue as opposed to one protected by a <a href="https://mastodon.bsd.cafe/tags/mutex" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>mutex</span></a>. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed. 😆</p><p>So I read some scientific papers 🙈 ... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. 🤩 Maybe it could do even more, didn't try yet.</p><p>Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...</p><p>(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: <a href="https://dl.acm.org/doi/10.1145/248052.248106" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">dl.acm.org/doi/10.1145/248052.</span><span class="invisible">248106</span></a></p>
Felix Palmen :freebsd: :c64:<p>I'm trying to add "genric" <a href="https://mastodon.bsd.cafe/tags/signal" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>signal</span></a> handling to <a href="https://mastodon.bsd.cafe/tags/poser" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>poser</span></a>. Ultimate goal is to provide a way for <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> to handle <a href="https://mastodon.bsd.cafe/tags/SIGHUP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SIGHUP</span></a>, although signal handling must be done in poser's main event loop (signals are only ever unblocked while waiting for file descriptor events).</p><p>Okay, I could just add explicit handling for SIGHUP. But a generic solution would be nicer. Just for example, a consumer might be interested in <a href="https://mastodon.bsd.cafe/tags/SIGINFO" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SIGINFO</span></a> which doesn't even exist on all platforms ... 🤔 </p><p>Now, <a href="https://mastodon.bsd.cafe/tags/POSIX" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>POSIX</span></a> specs basically just say signal constants are "integer values". Not too helpful here. Is it safe to assume an upper bound for signal numbers on "real world" OS implementations, e.g. 64 like on <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a>? Should I check <a href="https://mastodon.bsd.cafe/tags/NSIG" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NSIG</span></a> and, if not defined, just define it to 64? 🙈 </p><p><a href="https://mastodon.bsd.cafe/tags/C" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>C</span></a> <a href="https://mastodon.bsd.cafe/tags/coding" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>coding</span></a> <a href="https://mastodon.bsd.cafe/tags/question" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>question</span></a></p>
Felix Palmen :freebsd: :c64:<p>Next <a href="https://mastodon.bsd.cafe/tags/swad" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>swad</span></a> improvement: Make sure to <a href="https://mastodon.bsd.cafe/tags/wipe" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wipe</span></a> <a href="https://mastodon.bsd.cafe/tags/passwords" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>passwords</span></a> from RAM directly after used. That's more of a <a href="https://mastodon.bsd.cafe/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>security</span></a> precaution, because there *should* be no way how an attacker can access a running process' memory, but you never know which bugs surface 🙈.</p><p>Unexpectedly, that posed <a href="https://mastodon.bsd.cafe/tags/portability" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>portability</span></a> issues. <a href="https://mastodon.bsd.cafe/tags/C11" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>C11</span></a> has <a href="https://mastodon.bsd.cafe/tags/memset_s" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>memset_s</span></a> ... a pretty weird function, but suitable for wiping. It's there on <a href="https://mastodon.bsd.cafe/tags/FreeBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>FreeBSD</span></a> and on <a href="https://mastodon.bsd.cafe/tags/OpenBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>OpenBSD</span></a>. Not on <a href="https://mastodon.bsd.cafe/tags/NetBSD" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>NetBSD</span></a> though. But NetBSD offers the much saner <a href="https://mastodon.bsd.cafe/tags/C23" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>C23</span></a> function <a href="https://mastodon.bsd.cafe/tags/memset_explicit" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>memset_explicit</span></a>. Looking at <a href="https://mastodon.bsd.cafe/tags/Linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Linux</span></a>, there's neither. But there is the (non-standard!) <a href="https://mastodon.bsd.cafe/tags/explicit_bzero" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>explicit_bzero</span></a> 🤯 .. and with glibc, it requires _DEFAULT_SOURCE to be defined as soon as you compile with a C standard version given to the compiler. This function exists on some other systems as well, but there's confusion whether it should be declared in string.h or strings.h. 🤪 </p><p>Here's the full set of compile-tests I'm now doing, only to find the best way to really erase memory:<br><a href="https://github.com/Zirias/swad/blob/master/src/bin/swad/swad.mk#L6" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">github.com/Zirias/swad/blob/ma</span><span class="invisible">ster/src/bin/swad/swad.mk#L6</span></a></p><p>And if none of these functions is found, swad uses the "hacky" way that most likely works as well: Access the normal memset function via a volatile pointer.</p>