Problems running TOR for an extended period
Nick Mathewson
nickm at freehaven.net
Mon Jul 17 14:47:11 UTC 2006
On Mon, Jul 17, 2006 at 02:46:07PM +0200, Jan Danielsson wrote:
[...]
> No offense taken. However, the wiki I was pointer to earlier in this
> thread is a bit to flammable for my tastes. From
> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerOS:
>
> "[---] If you want to run a Tor server, we recommend you upgrade to a
> better OS."
>
> Although this wiki is linked to from the TOR site, I am unsure if it
> is an official TOR wiki, so this may be off-topic. I am also not sure if
> the quote above is meant to say "[...] a better OS [for running a TOR
> server]" or "[...] a better OS [period!]". If the latter is intended, I
> suggest someone change it, because I don't feel that a TOR wiki is the
> place for OS advocacy.
As noted, it's a wiki, so you can change it. As an alternative to
"better," I'd suggest "more up-to-date" or "more thread-friendly" or
"more appropriate".
> Also, the statement is pointless in the sense that I highly doubt
> that many users are about to switch operating system just to run TOR. I
> may be wrong, but I know I certainly wouldn't -- even though I very much
> am a supporter of what TOR is trying to accomplish.
>
> Anyway, even if OS advocacy wasn't intended, it's still pretty
> flammable, imho. It would be better to mention that in NetBSD-current,
> the gethostbyname_r() problems should be fixed.
Can you confirm this with a link? Better yet, can you alter the wiki
to say the right thing?
> Or mention other
> possible future directions which may work around such problems, and ask
> for help from the BSD community.
>
> > OpenBSD claims to have a gethostbyname_r, but it is
> > lying: it just #defines gethostbyname_r to gethostbyname. (This is
> > the moral equivalent of keeping your rat poison in a jar labeled
> > "cookies".)
>
> I know.. I have used API:s which I though were reentrant and mt-safe
> but turned out not to be. It was an "interesting" exercise, as in "what
> an interesting brain tumor you have". But in my case it wasn't
> mislabeled; it was my own fault for not reading the document
> introduction properly.
<off-topic rant>This is actually _worse_ in the OpenBSD case. The
only reason to provide gethostbyname_r in addition to gethostbyname is
that _r is supposed to be reentrant. All standards and documentation
say so. There's no reason to provide a _r that isn't reentrant,
unless you want to confuse people who use autoconf to try to find a
reentrant gethostbyname(). This is just a bad decision on the
implementors' part, period.</>
> >> As a side note, I don't understand why the calls to gethostbyname()
> >> can't be mutex'd on BSD systems, rather than just switching over to an
> >> all fork'd design. Are there other calls which are affected as well?
> >
> > We _could_ go multithreaded and make it block, but performance on exit
> > nodes would suck. When two users wanted to make exit connections at
> > the same time, one wouldn't start a DNS lookup until the other was
> > done. Also, an attacker could shut down all DNS requests just by
> > making requests that would take a long time to complete.
>
> Ah, obviously. I never even thought of DNS lookups as being slow. :-/
Oh, it happens. All you need is one domain with slow DNS for the
attack to work.
> > Right now, we're trying a different approach. In version 0.1.2.x,
> > we're trying an approach where we add a built-in async DNS resolver to
> > Tor and don't use the platform DNS resolver at all: this way, we don't
> > need to be multithreaded. Right now, it seems to have a bug that
> > creates a periodic segfault, but watch this space: I hope we'll get it
> > straightened out soon.
>
> Oh, so the actual code (+ bug) is already there? Neat. I'll take a
> look. Is a new release, with built in DNS resolver, planned for the near
> future?
It's in CVS; feel free to check it out? It's very much alpha, so it
probably won't be an official non-alpha release for the next couple of
months at least.
yrs,
--
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 654 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20060717/d77065a4/attachment.pgp>
More information about the tor-talk
mailing list