On Thursday 11 December 2008 20:39:41 Huang Ying wrote: > On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote: > > Engines like eng_cryptodev.c *are* built in (they're in > > ./crypto/engine/ rather ./engines/) and the intention is that they > > should be the implementation "de base" for those build targets to > > which they apply. Cryptodev is the only one so far, but there could > > be others. In fact, the padlock support for VIA chips (which is > > comparable to what's being discussed here, with all due respect to > > the intel instruction-set faithful) sits in ./engines like any other > > h/w support - a similar argument could be made that, on chips that > > support it, it should provide the default implementation(s), but > > right now they've been happy enough to make it a non-default option. > > The difference between Intel AES-NI and padlock is that padlock > provide support for different modes directly including ecb, cbc, cfb > and ofb, while Intel AES-NI just provides instructions for AES core > block algorithm NOT for modes directly. At the same time, AES-NI > pipelining implementation can benefit ecb encrypt and cbc decrypt and > counter mode. > > If we implement AES-NI with "branch", we can get full power of AES-NI > except ecb and ctr mode. > > If we implement AES-NI with "engine", we can get full power of AES-NI > for all modes. But we must duplicate mode implementations that can not > benefit from AES-NI, such as cfb, ofb, etc. > > Do you OK with code duplication?
The cipher and digest support is at the granularity of "nid"s, and these combine algorithm, key-length, and mode. So if you implement support for those cipher,length,mode combinations that can be accelerated by AES-NI, your engine will only be invoked for those combinations. You're not obliged to implement anything else, and indeed there is nothing to be gained by doing so. Please look at the padlock engine implementation, particularly the use of the DECLARE_AES_EVP macro. I humbly suggest this is a better way to go. However I see no reason why it couldn't go into crypto/engine/ (like eng_cryptodev.c) rather than in engines/ (like e_padlock.c) so that it is compiled in and loaded by default. Also, the load function for your engine could perform the run-time check for processor type, and only register its implementations with the engine infrastructure if the processor supports the AES-NI extensions (similar to padlock_available() for example). It would then suffice to add the -DHAVE_INTEL_AES_NI define to applicable build targets in Configure (presumably x86_64-related targets). Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
