[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Hardware accel by default
On Thu, Sep 8, 2011 at 1:18 PM, coderman <coderman@xxxxxxxxx> wrote:
>> My question is... Why wasn't AES-NI taken advantage of by default? Why
>> did I have to come across it by accident?
> some engines are actually slower than host optimized code.
> hw accel is experimental, and by default all providers in an engine
> are used. aesni is specific (aes only) but something like pkcs11 could
> use acceleration where not intended (montmult accel is fast but aes is
> slow, for example).
> if an engine is loaded (device present) and fails there is no graceful
> fallback, this could leave Tor broken in a way that is hard to
> diagnose via logs or traces. by explicitly enabling this, you are
> assumed to know what you're doing.
> probably other reasons i've overlooked...
The big reason that hardware acceleration isn't on by default is that
when we tried it, we found that some versions of some hardware
acceleration modules, on some versions of Tor, used with some versions
of OpenSSL, made Tor crash ... and we weren't able to do a good job of
tracking down which ones were safe.
Probably a better approach would be to try to investigate which
engines, when used with which versions of openssl, should be on by
default -- and add infrastructure to look for those particularly and
try to turn them on. Generally I'd limit this to things that are
supported automatically on CPUs or in common chipsets: that is, to the
hardware crypto acceleration that people are reasonably likely to have
without knowing they've got it. I'd also err on the side of only
enabling it with unusually recent versions of openssl, so as not to
have to deal with all of the known bugs in older versions.
I've added a bugtracker ticket for this at
tor-talk mailing list