On Fri, 2010-03-26 at 18:31 +0100, Andy Polyakov wrote: > > My question was about the inconsistency between, for example, > > SSE-optimised and AESNI-optimised functions. Both are implemented as > > perlasm; that's not relevant. What _is_ relevant, however, is that the > > SSE optimisations end up in the 'core' AES_encrypt() function which is > > tested by 'openssl speed aes', while the AESNI version is in an engine > > and isn't even used by default unless the application explicitly asks > > for it. > > > > My patch (unapplied for 6 months now) would at least fix the problem of > > the AESNI engine not being used automatically, > > The reason for low priority is that the code is in development,
The current state is actually fairly stable; it hasn't had a significant change since last May. There's more development to come (for CCM, other forms of combined MAC+ENC operation as cache-locality optimisations, etc.) but all that depends on other changes in OpenSSL -- so what we have at the moment is going into active use as it is. Hence my backporting it to 0.9.8 and 1.0.0 and making it available to users and Linux distributions. I'd be happy with our current code getting into those branches (it's just a new engine; no ABI changes¹) and letting the new stuff happen in later 1.0.x or 1.1.0). In the meantime, it does kind of suck that I can't even say 'just use OpenSSL HEAD; it works there'. > lack of hardware... The hardware is coming, and it's going to be common. I'm in the unenviable position that I need to be enabling this _early_ in slow-moving OS distributions such as RHEL6, and other products with a lifetime measured in years, so that it'll work properly on the hardware when it _does_ arrive. That's why I'm working on the backports and getting them into distributions right now, rather than waiting. If it's an issue that nobody in the core OpenSSL team has appropriate hardware RIGHT NOW, then we may perhaps be able to do something about that... let me know if you want me to follow that up. No promises, though. > > but I still don't quite understand why it should be an engine while > > SSE support is not. I'd like to understand the logic. <snip> Thank you very much for the explanation. I'd read through the previous threads from the time it was originally submitted, but had failed to pick out the important details. It makes a lot more sense to me now. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ That is, as long as I fudge around the 64-bit OPENSSL_ia32_cap issue, there are no ABI changes :) ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
