[tor-relays] BWAUTH weightings too volatile. . ."twitchy"

starlight.2015q2 at binnacle.cx starlight.2015q2 at binnacle.cx
Sat Jun 6 18:37:01 UTC 2015


At 04:12 6/7/2015 +1000, teor wrote:
>Please let me know how you go - the 0.2.6.x
>series should also be relatively ASAN
>and UBSAN clean, as Tor has been tested
>with them since late 2014.

I've run 0.2.4.x and 0.2.5.x with ASAN
live in production with no problems
when the relay had less bandwidth.
Performance hit is something like
30% extra CPU.  Also had it on
libssl.so and libevent.so, but
was too expensive to run on
libcrypto.so.

UBSAN seems expense and doesn't seem
it would run other than test, but
I didn't work on it long and am not
100% certain.  Was trying ASAN extra
stack checking at the time, which may
have been the culprit.

Did crash out with a good analysis report
the day Heartbleed was announced due to
someone scanning all the nodes for
the vuln.

After a major bandwidth increase, have
held off waiting for the bandwidth
weight to stabilize before trying it.

However the with the insanity of the
BWauths, I haven't done much with it.
Ran it awhile back and the consensus
took a modest hit, but the numbers
are so unreliable I couldn't tell
if it was ASAN overhead or plain
randomness.

The idea is not to use ASAN for a one
off test, but to run it 100% in production
so that an exploit showing up out-of-the
blue might be caught out.

Later this year Intel is releasing new
CPUs with hardware support for
new UBSAN checks.  That's something
I want to try.



More information about the tor-relays mailing list