Hi, > 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...
Thanks for the update, this looks cool. > > 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... Yes indeed, this is exactly what that stuff is for. Note however that the application still needs to call that function, so you still have the problem that only "enabled" applications will give you any hook to ensure the engine is loaded. However it has the benefit of being a single hook that can allow a config file to control all potential functionalities, rather than apps having to add ENGINE_load_***(), (etc) calls on a per-case basis. On the other hand, it might be desirable to build openssl libs that perform this autoconfiguration every time they're used, rather than just for applications that see fit to call it. This came up in a chat with Steve some time back (he was the one that did the config-module work), though I don't know whether anything ended up in there to let you hard-code config-loading into the openssl libs. If not, it was probably just for lack of a conviction of whether it was worth doing, or for lack of a preferred mechanism/semantic for it. Steve, can you comment? > BTW What's the reason for not loading engines by default but only > explicitly through ENGINE_...() functions? The startup speed? Any other > risks? Ah, well there's a couple of reasons. One was that, originally, it was desirable that the ENGINE code wasn't statically linked into any application that didn't make ENGINE API calls. Ie. not interferring in any legacy scenarios. The second is that the ENGINE code at the time would statically link in all the crypto code for *all* functionality supported by ENGINE. Ie. if you used ENGINE for RSA, you'd get all the DSA, RAND, (etc) baggage anyway. The second point is no longer an issue and the first is probably less relevant now that we're a couple of versions further on. However I'd probably need to take another cleanup-stick to the engine code before considering any "auto-loading" option there, and there also the issue of deciding how the auto-loading would happen: it's less than obvious in some cases (first-use-initialisation hacks can have some non-trivial drawbacks). But with the above notes aside, the configuration-file stuff is perhaps a better and more general nut to crack. There are also some similar issues, eg. if the config file support *could* cause a DSA key to be loaded if the config file specified to do so, then the library would necessarily link to the DSA functionality whether it was used in the config file or not (unless you were careful about using RTLD_LAZY, which still isn't a solution for some platforms). Input would no doubt be welcome on these types of issues, particular from Suse hackers or any other "distribution" gurus our there. > > 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. OK, one quick observation right off - you'd probably need to home this in on linux-x86, as non-linux platforms (and/or compilers) would probably croak on some or all of this. Particularly with the use of "__func__". :-) > 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... Can be this be made 486-safe? If so, and the code was made friendlier to non-linux x86 kernels (and non-gcc compilers), we'd be up and running. > > 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"? The Configure script (invoked by ./config if you choose to go that way) uses different targets for different compiler/OS/CPU combinations. And whatever else is required to build without using autoconf. Run; perl Configure -? Cheers, Geoff -- Geoff Thorpe, RT/openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
