Geoff Thorpe via RT told me that: >>OK, attached is a patch against CVS mainline. For me it works in both >>static and shared versions. > > Cool, I'll try to take a look in the next few days.
Getting back to this as I just finished an updated version of the PadLock engine with support for AES192, AES256 and RNG. For now it is only for 0.9.7 (see http://www.logix.cz/michal/devel/padlock/#openssl) and before porting it to CVS I want to clarify how... >>I didn't get it, sorry. Should I make the Padlock support always static >>as is the cryptodev? The PadLock is available on new VIA Nehemiah CPUs >>and if present (and successfully detected by the Padlock engine >>initialization routine) it should be used, yes. But that's the same >>situation as with other engines, isn't it? > > Not necessarily - I am still unsure of whether we should attempt to > automatically probe shared-lib engines during > ENGINE_load_builtin_engines(). Right now, no shared-lib engines will be > available unless they're loaded or specified by id, so you'd > automatically fall back to the default software implementations. Hmm, that's unfortunate. May OPENSSL_config() have any influence on it? I haven't looked at the possibilities of configuring engines through openssl.cnf yet, but if something like... [engines] load = padlock atalla ... would be possible, then it could be parsed and used even in ENGINE_load_builtin_engines(). BTW What's the reason for not loading engines by default but only explicitly through ENGINE_...() functions? The startup speed? Any other risks? > I could go with compiling the padlock engine statically a la cryptodev > iff we can ensure that it is only compiled on supported platforms. On non-i386 ENGINE_load_padlock() immediately returns and the rest is also #ifdef'ed and compiles only on i386. > The > reason we can "compile-in" cryptodev is that it becomes a NOP except on > openbsd and any other platform that supports cryptodev or is prepared to > accept the additional overhead even if it isn't supported. I don't think > a large class of x86 platform targets would accept such a situation with > the padlock stuff given that the majority of run-time environments > wouldn't be able to use it. OTOH the startup check for PadLock availability is really quick and simple - only two 'cpuid' instructions and parsing their output. No need to dlopen() other libraries, no need to wait for hardware initialization, etc. IMHO it could be safely compiled in... > Is there anything else specific about > "padlock-capable" systems that could be used to set specific targets for > this stuff? Sorry, what do you mean by "specific target"? Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
