[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Problems running TOR for an extended period



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

Attachment: pgpfkNw0IzvNb.pgp
Description: PGP signature