Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
Date: Sat, 06 Jun 2015 02:43:09 -0400 From: starlight.2015q2@binnacle.cx
… One reason this vexes is that I would like to see how well the relay runs with Address Sanitizer active. ASAN provides obvious benefits w/r/t security, but entails a performance trade-off. With the BWauths throwing darts, eyes closed, when choosing weighting, it's impossible to gauge the performance impact of various adjustments. …
Good timing! Tor 0.2.7.1-alpha on x86_64 is currently Address Sanitizer and Undefined Behavior Sanitizer clean. I've just submitted a branch with instructions for building, running, and testing Tor with ASAN and UBSAN. https://trac.torproject.org/projects/tor/ticket/15817#comment:8 The following known issues exist: Two of the tests deliberately invoke undefined / illegal behavior, the instructions provide a blacklist file and an environmental variable to exempt them from ASAN/UBSAN. Architectures without (x86?) 64-bit assembler use donna C code that left-shifts 1 bits into and past the sign bit of signed integers. Until https://trac.torproject.org/projects/tor/ticket/13538 is resolved, this particular file can be exempted from UBSAN. 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. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7
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.
participants (2)
-
starlight.2015q2＠binnacle.cx -
teor