From 15b5d84f9da2ce4bfae8580e56e34a859f74ad71 Mon Sep 17 00:00:00 2001 From: markus <> Date: Thu, 5 Sep 2002 12:51:50 +0000 Subject: import openssl-0.9.7-beta1 --- src/lib/libcrypto/engine/README | 483 ++++++++++++--------------- src/lib/libcrypto/engine/eng_all.c | 22 +- src/lib/libcrypto/engine/eng_fat.c | 3 +- src/lib/libcrypto/engine/eng_init.c | 3 +- src/lib/libcrypto/engine/eng_list.c | 2 +- src/lib/libcrypto/engine/engine.h | 650 +++++++++++++++++++++++++++--------- 6 files changed, 697 insertions(+), 466 deletions(-) (limited to 'src/lib/libcrypto/engine') diff --git a/src/lib/libcrypto/engine/README b/src/lib/libcrypto/engine/README index 96595e6f35..6b69b70f57 100644 --- a/src/lib/libcrypto/engine/README +++ b/src/lib/libcrypto/engine/README @@ -1,278 +1,211 @@ -NOTES, THOUGHTS, and EVERYTHING -------------------------------- - -(1) Concurrency and locking ... I made a change to the ENGINE_free code - because I spotted a potential hold-up in proceedings (doing too - much inside a lock including calling a callback), there may be - other bits like this. What do the speed/optimisation freaks think - of this aspect of the code and design? There's lots of locking for - manipulation functions and I need that to keep things nice and - solid, but this manipulation is mostly (de)initialisation, I would - think that most run-time locking is purely in the ENGINE_init and - ENGINE_finish calls that might be made when getting handles for - RSA (and friends') structures. These would be mostly reference - count operations as the functional references should always be 1 - or greater at run-time to prevent init/deinit thrashing. - -(2) nCipher support, via the HWCryptoHook API, is now in the code. - Apparently this hasn't been tested too much yet, but it looks - good. :-) Atalla support has been added too, but shares a lot in - common with Ben's original hooks in bn_exp.c (although it has been - ENGINE-ified, and error handling wrapped around it) and it's also - had some low-volume testing, so it should be usable. - -(3) Of more concern, we need to work out (a) how to put together usable - RAND_METHODs for units that just have one "get n or less random - bytes" function, (b) we also need to determine how to hook the code - in crypto/rand/ to use the ENGINE defaults in a way similar to what - has been done in crypto/rsa/, crypto/dsa/, etc. - -(4) ENGINE should really grow to encompass more than 3 public key - algorithms and randomness gathering. The structure/data level of - the engine code is hidden from code outside the crypto/engine/ - directory so change shouldn't be too viral. More important though - is how things should evolve ... this needs thought and discussion. - - ------------------------------------==*==----------------------------------- - -More notes 2000-08-01 ---------------------- - -Geoff Thorpe, who designed the engine part, wrote a pretty good description -of the thoughts he had when he built it, good enough to include verbatim here -(with his permission) -- Richard Levitte - - -Date: Tue, 1 Aug 2000 16:54:08 +0100 (BST) -From: Geoff Thorpe -Subject: Re: The thoughts to merge BRANCH_engine into the main trunk are - emerging - -Hi there, - -I'm going to try and do some justice to this, but I'm a little short on -time and the there is an endless amount that could be discussed on this -subject. sigh ... please bear with me :-) - -> The changes in BRANCH_engine dig deep into the core of OpenSSL, for example -> into the RSA and RAND routines, adding a level of indirection which is needed -> to keep the abstraction, as far as I understand. It would be a good thing if -> those who do play with those things took a look at the changes that have been -> done in the branch and say out loud how much (or hopefully little) we've made -> fools of ourselves. - -The point here is that the code that has emerged in the BRANCH_engine -branch was based on some initial requirements of mine that I went in and -addressed, and Richard has picked up the ball and run with it too. It -would be really useful to get some review of the approach we've taken, but -first I think I need to describe as best I can the reasons behind what has -been done so far, in particular what issues we have tried to address when -doing this, and what issues we have intentionally (or necessarily) tried -to avoid. - -methods, engines, and evps --------------------------- - -There has been some dicussion, particularly with Steve, about where this -ENGINE stuff might fit into the conceptual picture as/when we start to -abstract algorithms a little bit to make the library more extensible. In -particular, it would desirable to have algorithms (symmetric, hash, pkc, -etc) abstracted in some way that allows them to be just objects sitting in -a list (or database) ... it'll just happen that the "DSA" object doesn't -support encryption whereas the "RSA" object does. This requires a lot of -consideration to begin to know how to tackle it; in particular how -encapsulated should these things be? If the objects also understand their -own ASN1 encodings and what-not, then it would for example be possible to -add support for elliptic-curve DSA in as a new algorithm and automatically -have ECC-DSA certificates supported in SSL applications. Possible, but not -easy. :-) - -Whatever, it seems that the way to go (if I've grok'd Steve's comments on -this in the past) is to amalgamate these things in EVP as is already done -(I think) for ciphers or hashes (Steve, please correct/elaborate). I -certainly think something should be done in this direction because right -now we have different source directories, types, functions, and methods -for each algorithm - even when conceptually they are very much different -feathers of the same bird. (This is certainly all true for the public-key -stuff, and may be partially true for the other parts.) - -ENGINE was *not* conceived as a way of solving this, far from it. Nor was -it conceived as a way of replacing the various "***_METHOD"s. It was -conceived as an abstraction of a sort of "virtual crypto device". If we -lived in a world where "EVP_ALGO"s (or something like them) encapsulated -particular algorithms like RSA,DSA,MD5,RC4,etc, and "***_METHOD"s -encapsulated interfaces to algorithms (eg. some algo's might support a -PKC_METHOD, a HASH_METHOD, or a CIPHER_METHOD, who knows?), then I would -think that ENGINE would encapsulate an implementation of arbitrarily many -of those algorithms - perhaps as alternatives to existing algorithms -and/or perhaps as new previously unimplemented algorithms. An ENGINE could -be used to contain an alternative software implementation, a wrapper for a -hardware acceleration and/or key-management unit, a comms-wrapper for -distributing cryptographic operations to remote machines, or any other -"devices" your imagination can dream up. - -However, what has been done in the ENGINE branch so far is nothing more -than starting to get our toes wet. I had a couple of self-imposed -requirements when putting the initial abstraction together, and I may have -already posed these in one form or another on the list, but briefly; - - (i) only bother with public key algorithms for now, and maybe RAND too - (motivated by the need to get hardware support going and the fact - this was a comparitively easy subset to address to begin with). - - (ii) don't change (if at all possible) the existing crypto code, ie. the - implementations, the way the ***_METHODs work, etc. - - (iii) ensure that if no function from the ENGINE code is ever called then - things work the way they always did, and there is no memory - allocation (otherwise the failure to cleanup would be a problem - - this is part of the reason no STACKs were used, the other part of - the reason being I found them inappropriate). - - (iv) ensure that all the built-in crypto was encapsulated by one of - these "ENGINE"s and that this engine was automatically selected as - the default. - - (v) provide the minimum hooking possible in the existing crypto code - so that global functions (eg. RSA_public_encrypt) do not need any - extra parameter, yet will use whatever the current default ENGINE - for that RSA key is, and that the default can be set "per-key" - and globally (new keys will assume the global default, and keys - without their own default will be operated on using the global - default). NB: Try and make (v) conflict as little as possible with - (ii). :-) - - (vi) wrap the ENGINE code up in duct tape so you can't even see the - corners. Ie. expose no structures at all, just black-box pointers. - - (v) maintain internally a list of ENGINEs on which a calling - application can iterate, interrogate, etc. Allow a calling - application to hook in new ENGINEs, remove ENGINEs from the list, - and enforce uniqueness within the global list of each ENGINE's - "unique id". - - (vi) keep reference counts for everything - eg. this includes storing a - reference inside each RSA structure to the ENGINE that it uses. - This is freed when the RSA structure is destroyed, or has its - ENGINE explicitly changed. The net effect needs to be that at any - time, it is deterministic to know whether an ENGINE is in use or - can be safely removed (or unloaded in the case of the other type - of reference) without invalidating function pointers that may or - may not be used indavertently in the future. This was actually - one of the biggest problems to overcome in the existing OpenSSL - code - implementations had always been assumed to be ever-present, - so there was no trivial way to get round this. - - (vii) distinguish between structural references and functional - references. - -A *little* detail +Notes: 2001-09-24 ----------------- -While my mind is on it; I'll illustrate the bit in item (vii). This idea -turned out to be very handy - the ENGINEs themselves need to be operated -on and manipulated simply as objects without necessarily trying to -"enable" them for use. Eg. most host machines will not have the necessary -hardware or software to support all the engines one might compile into -OpenSSL, yet it needs to be possible to iterate across the ENGINEs, -querying their names, properties, etc - all happening in a thread-safe -manner that uses reference counts (if you imagine two threads iterating -through a list and one thread removing the ENGINE the other is currently -looking at - you can see the gotcha waiting to happen). For all of this, -*structural references* are used and operate much like the other reference -counts in OpenSSL. - -The other kind of reference count is for *functional* references - these -indicate a reference on which the caller can actually assume the -particular ENGINE to be initialised and usable to perform the operations -it implements. Any increment or decrement of the functional reference -count automatically invokes a corresponding change in the structural -reference count, as it is fairly obvious that a functional reference is a -restricted case of a structural reference. So struct_ref >= funct_ref at -all times. NB: functional references are usually obtained by a call to -ENGINE_init(), but can also be created implicitly by calls that require a -new functional reference to be created, eg. ENGINE_set_default(). Either -way the only time the underlying ENGINE's "init" function is really called -is when the (functional) reference count increases to 1, similarly the -underlying "finish" handler is only called as the count goes down to 0. -The effect of this, for example, is that if you set the default ENGINE for -RSA operations to be "cswift", then its functional reference count will -already be at least 1 so the CryptoSwift shared-library and the card will -stay loaded and initialised until such time as all RSA keys using the -cswift ENGINE are changed or destroyed and the default ENGINE for RSA -operations has been changed. This prevents repeated thrashing of init and -finish handling if the count keeps getting down as far as zero. - -Otherwise, the way the ENGINE code has been put together I think pretty -much reflects the above points. The reason for the ENGINE structure having -individual RSA_METHOD, DSA_METHOD, etc pointers is simply that it was the -easiest way to go about things for now, to hook it all into the raw -RSA,DSA,etc code, and I was trying to the keep the structure invisible -anyway so that the way this is internally managed could be easily changed -later on when we start to work out what's to be done about these other -abstractions. - -Down the line, if some EVP-based technique emerges for adequately -encapsulating algorithms and all their various bits and pieces, then I can -imagine that "ENGINE" would turn into a reference-counting database of -these EVP things, of which the default "openssl" ENGINE would be the -library's own object database of pre-built software implemented algorithms -(and such). It would also be cool to see the idea of "METHOD"s detached -from the algorithms themselves ... so RSA, DSA, ElGamal, etc can all -expose essentially the same METHOD (aka interface), which would include -any querying/flagging stuff to identify what the algorithm can/can't do, -its name, and other stuff like max/min block sizes, key sizes, etc. This -would result in ENGINE similarly detaching its internal database of -algorithm implementations from the function definitions that return -interfaces to them. I think ... - -As for DSOs etc. Well the DSO code is pretty handy (but could be made much -more so) for loading vendor's driver-libraries and talking to them in some -generic way, but right now there's still big problems associated with -actually putting OpenSSL code (ie. new ENGINEs, or anything else for that -matter) in dynamically loadable libraries. These problems won't go away in -a hurry so I don't think we should expect to have any kind of -shared-library extensions any time soon - but solving the problems is a -good thing to aim for, and would as a side-effect probably help make -OpenSSL more usable as a shared-library itself (looking at the things -needed to do this will show you why). - -One of the problems is that if you look at any of the ENGINE -implementations, eg. hw_cswift.c or hw_ncipher.c, you'll see how it needs -a variety of functionality and definitions from various areas of OpenSSL, -including crypto/bn/, crypto/err/, crypto/ itself (locking for example), -crypto/dso/, crypto/engine/, crypto/rsa, etc etc etc. So if similar code -were to be suctioned off into shared libraries, the shared libraries would -either have to duplicate all the definitions and code and avoid loader -conflicts, or OpenSSL would have to somehow expose all that functionality -to the shared-library. If this isn't a big enough problem, the issue of -binary compatibility will be - anyone writing Apache modules can tell you -that (Ralf? Ben? :-). However, I don't think OpenSSL would need to be -quite so forgiving as Apache should be, so OpenSSL could simply tell its -version to the DSO and leave the DSO with the problem of deciding whether -to proceed or bail out for fear of binary incompatibilities. - -Certainly one thing that would go a long way to addressing this is to -embark on a bit of an opaqueness mission. I've set the ENGINE code up with -this in mind - it's so draconian that even to declare your own ENGINE, you -have to get the engine code to create the underlying ENGINE structure, and -then feed in the new ENGINE's function/method pointers through various -"set" functions. The more of the code that takes on such a black-box -approach, the more of the code that will be (a) easy to expose to shared -libraries that need it, and (b) easy to expose to applications wanting to -use OpenSSL itself as a shared-library. From my own explorations in -OpenSSL, the biggest leviathan I've seen that is a problem in this respect -is the BIGNUM code. Trying to "expose" the bignum code through any kind of -organised "METHODs", let alone do all the necessary bignum operations -solely through functions rather than direct access to the structures and -macros, will be a massive pain in the "r"s. - -Anyway, I'm done for now - hope it was readable. Thoughts? - -Cheers, -Geoff - - ------------------------------------==*==----------------------------------- +This "description" (if one chooses to call it that) needed some major updating +so here goes. This update addresses a change being made at the same time to +OpenSSL, and it pretty much completely restructures the underlying mechanics of +the "ENGINE" code. So it serves a double purpose of being a "ENGINE internals +for masochists" document *and* a rather extensive commit log message. (I'd get +lynched for sticking all this in CHANGES or the commit mails :-). + +ENGINE_TABLE underlies this restructuring, as described in the internal header +"eng_int.h", implemented in eng_table.c, and used in each of the "class" files; +tb_rsa.c, tb_dsa.c, etc. + +However, "EVP_CIPHER" underlies the motivation and design of ENGINE_TABLE so +I'll mention a bit about that first. EVP_CIPHER (and most of this applies +equally to EVP_MD for digests) is both a "method" and a algorithm/mode +identifier that, in the current API, "lingers". These cipher description + +implementation structures can be defined or obtained directly by applications, +or can be loaded "en masse" into EVP storage so that they can be catalogued and +searched in various ways, ie. two ways of encrypting with the "des_cbc" +algorithm/mode pair are; + +(i) directly; + const EVP_CIPHER *cipher = EVP_des_cbc(); + EVP_EncryptInit(&ctx, cipher, key, iv); + [ ... use EVP_EncryptUpdate() and EVP_EncryptFinal() ...] + +(ii) indirectly; + OpenSSL_add_all_ciphers(); + cipher = EVP_get_cipherbyname("des_cbc"); + EVP_EncryptInit(&ctx, cipher, key, iv); + [ ... etc ... ] + +The latter is more generally used because it also allows ciphers/digests to be +looked up based on other identifiers which can be useful for automatic cipher +selection, eg. in SSL/TLS, or by user-controllable configuration. + +The important point about this is that EVP_CIPHER definitions and structures are +passed around with impunity and there is no safe way, without requiring massive +rewrites of many applications, to assume that EVP_CIPHERs can be reference +counted. One an EVP_CIPHER is exposed to the caller, neither it nor anything it +comes from can "safely" be destroyed. Unless of course the way of getting to +such ciphers is via entirely distinct API calls that didn't exist before. +However existing API usage cannot be made to understand when an EVP_CIPHER +pointer, that has been passed to the caller, is no longer being used. + +The other problem with the existing API w.r.t. to hooking EVP_CIPHER support +into ENGINE is storage - the OBJ_NAME-based storage used by EVP to register +ciphers simultaneously registers cipher *types* and cipher *implementations* - +they are effectively the same thing, an "EVP_CIPHER" pointer. The problem with +hooking in ENGINEs is that multiple ENGINEs may implement the same ciphers. The +solution is necessarily that ENGINE-provided ciphers simply are not registered, +stored, or exposed to the caller in the same manner as existing ciphers. This is +especially necessary considering the fact ENGINE uses reference counts to allow +for cleanup, modularity, and DSO support - yet EVP_CIPHERs, as exposed to +callers in the current API, support no such controls. + +Another sticking point for integrating cipher support into ENGINE is linkage. +Already there is a problem with the way ENGINE supports RSA, DSA, etc whereby +they are available *because* they're part of a giant ENGINE called "openssl". +Ie. all implementations *have* to come from an ENGINE, but we get round that by +having a giant ENGINE with all the software support encapsulated. This creates +linker hassles if nothing else - linking a 1-line application that calls 2 basic +RSA functions (eg. "RSA_free(RSA_new());") will result in large quantities of +ENGINE code being linked in *and* because of that DSA, DH, and RAND also. If we +continue with this approach for EVP_CIPHER support (even if it *was* possible) +we would lose our ability to link selectively by selectively loading certain +implementations of certain functionality. Touching any part of any kind of +crypto would result in massive static linkage of everything else. So the +solution is to change the way ENGINE feeds existing "classes", ie. how the +hooking to ENGINE works from RSA, DSA, DH, RAND, as well as adding new hooking +for EVP_CIPHER, and EVP_MD. + +The way this is now being done is by mostly reverting back to how things used to +work prior to ENGINE :-). Ie. RSA now has a "RSA_METHOD" pointer again - this +was previously replaced by an "ENGINE" pointer and all RSA code that required +the RSA_METHOD would call ENGINE_get_RSA() each time on its ENGINE handle to +temporarily get and use the ENGINE's RSA implementation. Apart from being more +efficient, switching back to each RSA having an RSA_METHOD pointer also allows +us to conceivably operate with *no* ENGINE. As we'll see, this removes any need +for a fallback ENGINE that encapsulates default implementations - we can simply +have our RSA structure pointing its RSA_METHOD pointer to the software +implementation and have its ENGINE pointer set to NULL. + +A look at the EVP_CIPHER hooking is most explanatory, the RSA, DSA (etc) cases +turn out to be degenerate forms of the same thing. The EVP storage of ciphers, +and the existing EVP API functions that return "software" implementations and +descriptions remain untouched. However, the storage takes more meaning in terms +of "cipher description" and less meaning in terms of "implementation". When an +EVP_CIPHER_CTX is actually initialised with an EVP_CIPHER method and is about to +begin en/decryption, the hooking to ENGINE comes into play. What happens is that +cipher-specific ENGINE code is asked for an ENGINE pointer (a functional +reference) for any ENGINE that is registered to perform the algo/mode that the +provided EVP_CIPHER structure represents. Under normal circumstances, that +ENGINE code will return NULL because no ENGINEs will have had any cipher +implementations *registered*. As such, a NULL ENGINE pointer is stored in the +EVP_CIPHER_CTX context, and the EVP_CIPHER structure is left hooked into the +context and so is used as the implementation. Pretty much how things work now +except we'd have a redundant ENGINE pointer set to NULL and doing nothing. + +Conversely, if an ENGINE *has* been registered to perform the algorithm/mode +combination represented by the provided EVP_CIPHER, then a functional reference +to that ENGINE will be returned to the EVP_CIPHER_CTX during initialisation. +That functional reference will be stored in the context (and released on +cleanup) - and having that reference provides a *safe* way to use an EVP_CIPHER +definition that is private to the ENGINE. Ie. the EVP_CIPHER provided by the +application will actually be replaced by an EVP_CIPHER from the registered +ENGINE - it will support the same algorithm/mode as the original but will be a +completely different implementation. Because this EVP_CIPHER isn't stored in the +EVP storage, nor is it returned to applications from traditional API functions, +there is no associated problem with it not having reference counts. And of +course, when one of these "private" cipher implementations is hooked into +EVP_CIPHER_CTX, it is done whilst the EVP_CIPHER_CTX holds a functional +reference to the ENGINE that owns it, thus the use of the ENGINE's EVP_CIPHER is +safe. + +The "cipher-specific ENGINE code" I mentioned is implemented in tb_cipher.c but +in essence it is simply an instantiation of "ENGINE_TABLE" code for use by +EVP_CIPHER code. tb_digest.c is virtually identical but, of course, it is for +use by EVP_MD code. Ditto for tb_rsa.c, tb_dsa.c, etc. These instantiations of +ENGINE_TABLE essentially provide linker-separation of the classes so that even +if ENGINEs implement *all* possible algorithms, an application using only +EVP_CIPHER code will link at most code relating to EVP_CIPHER, tb_cipher.c, core +ENGINE code that is independant of class, and of course the ENGINE +implementation that the application loaded. It will *not* however link any +class-specific ENGINE code for digests, RSA, etc nor will it bleed over into +other APIs, such as the RSA/DSA/etc library code. + +ENGINE_TABLE is a little more complicated than may seem necessary but this is +mostly to avoid a lot of "init()"-thrashing on ENGINEs (that may have to load +DSOs, and other expensive setup that shouldn't be thrashed unnecessarily) *and* +to duplicate "default" behaviour. Basically an ENGINE_TABLE instantiation, for +example tb_cipher.c, implements a hash-table keyed by integer "nid" values. +These nids provide the uniquenness of an algorithm/mode - and each nid will hash +to a potentially NULL "ENGINE_PILE". An ENGINE_PILE is essentially a list of +pointers to ENGINEs that implement that particular 'nid'. Each "pile" uses some +caching tricks such that requests on that 'nid' will be cached and all future +requests will return immediately (well, at least with minimal operation) unless +a change is made to the pile, eg. perhaps an ENGINE was unloaded. The reason is +that an application could have support for 10 ENGINEs statically linked +in, and the machine in question may not have any of the hardware those 10 +ENGINEs support. If each of those ENGINEs has a "des_cbc" implementation, we +want to avoid every EVP_CIPHER_CTX setup from trying (and failing) to initialise +each of those 10 ENGINEs. Instead, the first such request will try to do that +and will either return (and cache) a NULL ENGINE pointer or will return a +functional reference to the first that successfully initialised. In the latter +case it will also cache an extra functional reference to the ENGINE as a +"default" for that 'nid'. The caching is acknowledged by a 'uptodate' variable +that is unset only if un/registration takes place on that pile. Ie. if +implementations of "des_cbc" are added or removed. This behaviour can be +tweaked; the ENGINE_TABLE_FLAG_NOINIT value can be passed to +ENGINE_set_table_flags(), in which case the only ENGINEs that tb_cipher.c will +try to initialise from the "pile" will be those that are already initialised +(ie. it's simply an increment of the functional reference count, and no real +"initialisation" will take place). + +RSA, DSA, DH, and RAND all have their own ENGINE_TABLE code as well, and the +difference is that they all use an implicit 'nid' of 1. Whereas EVP_CIPHERs are +actually qualitatively different depending on 'nid' (the "des_cbc" EVP_CIPHER is +not an interoperable implementation of "aes_256_cbc"), RSA_METHODs are +necessarily interoperable and don't have different flavours, only different +implementations. In other words, the ENGINE_TABLE for RSA will either be empty, +or will have a single ENGING_PILE hashed to by the 'nid' 1 and that pile +represents ENGINEs that implement the single "type" of RSA there is. + +Cleanup - the registration and unregistration may pose questions about how +cleanup works with the ENGINE_PILE doing all this caching nonsense (ie. when the +application or EVP_CIPHER code releases its last reference to an ENGINE, the +ENGINE_PILE code may still have references and thus those ENGINEs will stay +hooked in forever). The way this is handled is via "unregistration". With these +new ENGINE changes, an abstract ENGINE can be loaded and initialised, but that +is an algorithm-agnostic process. Even if initialised, it will not have +registered any of its implementations (to do so would link all class "table" +code despite the fact the application may use only ciphers, for example). This +is deliberately a distinct step. Moreover, registration and unregistration has +nothing to do with whether an ENGINE is *functional* or not (ie. you can even +register an ENGINE and its implementations without it being operational, you may +not even have the drivers to make it operate). What actually happens with +respect to cleanup is managed inside eng_lib.c with the "engine_cleanup_***" +functions. These functions are internal-only and each part of ENGINE code that +could require cleanup will, upon performing its first allocation, register a +callback with the "engine_cleanup" code. The other part of this that makes it +tick is that the ENGINE_TABLE instantiations (tb_***.c) use NULL as their +initialised state. So if RSA code asks for an ENGINE and no ENGINE has +registered an implementation, the code will simply return NULL and the tb_rsa.c +state will be unchanged. Thus, no cleanup is required unless registration takes +place. ENGINE_cleanup() will simply iterate across a list of registered cleanup +callbacks calling each in turn, and will then internally delete its own storage +(a STACK). When a cleanup callback is next registered (eg. if the cleanup() is +part of a gracefull restart and the application wants to cleanup all state then +start again), the internal STACK storage will be freshly allocated. This is much +the same as the situation in the ENGINE_TABLE instantiations ... NULL is the +initialised state, so only modification operations (not queries) will cause that +code to have to register a cleanup. + +What else? The bignum callbacks and associated ENGINE functions have been +removed for two obvious reasons; (i) there was no way to generalise them to the +mechanism now used by RSA/DSA/..., because there's no such thing as a BIGNUM +method, and (ii) because of (i), there was no meaningful way for library or +application code to automatically hook and use ENGINE supplied bignum functions +anyway. Also, ENGINE_cpy() has been removed (although an internal-only version +exists) - the idea of providing an ENGINE_cpy() function probably wasn't a good +one and now certainly doesn't make sense in any generalised way. Some of the +RSA, DSA, DH, and RAND functions that were fiddled during the original ENGINE +changes have now, as a consequence, been reverted back. This is because the +hooking of ENGINE is now automatic (and passive, it can interally use a NULL +ENGINE pointer to simply ignore ENGINE from then on). + +Hell, that should be enough for now ... comments welcome: geoff@openssl.org diff --git a/src/lib/libcrypto/engine/eng_all.c b/src/lib/libcrypto/engine/eng_all.c index a35b3db9e8..b3030fe505 100644 --- a/src/lib/libcrypto/engine/eng_all.c +++ b/src/lib/libcrypto/engine/eng_all.c @@ -60,10 +60,6 @@ #include #include "eng_int.h" -#ifdef __OpenBSD__ -static int openbsd_default_loaded = 0; -#endif - void ENGINE_load_builtin_engines(void) { /* There's no longer any need for an "openssl" ENGINE unless, one day, @@ -96,23 +92,11 @@ void ENGINE_load_builtin_engines(void) #ifndef OPENSSL_NO_HW_SUREWARE ENGINE_load_sureware(); #endif +#ifndef OPENSSL_NO_HW_4758_CCA + ENGINE_load_4758cca(); +#endif #ifdef OPENSSL_OPENBSD_DEV_CRYPTO ENGINE_load_openbsd_dev_crypto(); #endif -#ifdef __OpenBSD__ - ENGINE_load_cryptodev(); -#endif #endif } - -#ifdef __OpenBSD__ -void ENGINE_setup_openbsd(void) { - if (!openbsd_default_loaded) { - ENGINE_load_cryptodev(); - ENGINE_register_all_complete(); - } - openbsd_default_loaded=1; -} -#endif - - diff --git a/src/lib/libcrypto/engine/eng_fat.c b/src/lib/libcrypto/engine/eng_fat.c index af918b1499..d49aa7ed40 100644 --- a/src/lib/libcrypto/engine/eng_fat.c +++ b/src/lib/libcrypto/engine/eng_fat.c @@ -141,8 +141,7 @@ int ENGINE_register_all_complete(void) { ENGINE *e; - for(e=ENGINE_get_first() ; e ; e=ENGINE_get_next(e)) { + for(e=ENGINE_get_first() ; e ; e=ENGINE_get_next(e)) ENGINE_register_complete(e); - } return 1; } diff --git a/src/lib/libcrypto/engine/eng_init.c b/src/lib/libcrypto/engine/eng_init.c index cc9396e863..98caa21e32 100644 --- a/src/lib/libcrypto/engine/eng_init.c +++ b/src/lib/libcrypto/engine/eng_init.c @@ -93,7 +93,7 @@ int engine_unlocked_finish(ENGINE *e, int unlock_for_handlers) * there's a chance that both threads will together take the count from * 2 to 0 without either calling finish(). */ e->funct_ref--; - engine_ref_debug(e, 1, -1); + engine_ref_debug(e, 1, -1) if((e->funct_ref == 0) && e->finish) { if(unlock_for_handlers) @@ -155,4 +155,3 @@ int ENGINE_finish(ENGINE *e) } return to_return; } - diff --git a/src/lib/libcrypto/engine/eng_list.c b/src/lib/libcrypto/engine/eng_list.c index ce48d2255a..0c220558e7 100644 --- a/src/lib/libcrypto/engine/eng_list.c +++ b/src/lib/libcrypto/engine/eng_list.c @@ -348,7 +348,7 @@ ENGINE *ENGINE_by_id(const char *id) } CRYPTO_r_lock(CRYPTO_LOCK_ENGINE); iterator = engine_list_head; - while(iterator && (strcmp(id, iterator->id) != 0)) + while(iterator && (strcmp(id, iterator->id) != 0)) iterator = iterator->next; if(iterator) { diff --git a/src/lib/libcrypto/engine/engine.h b/src/lib/libcrypto/engine/engine.h index 2983f47034..cf06618286 100644 --- a/src/lib/libcrypto/engine/engine.h +++ b/src/lib/libcrypto/engine/engine.h @@ -3,7 +3,7 @@ * project 2000. */ /* ==================================================================== - * Copyright (c) 1999 The OpenSSL Project. All rights reserved. + * Copyright (c) 1999-2001 The OpenSSL Project. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions @@ -59,36 +59,171 @@ #ifndef HEADER_ENGINE_H #define HEADER_ENGINE_H +#include #include +#ifndef OPENSSL_NO_RSA #include +#endif +#ifndef OPENSSL_NO_DSA #include +#endif +#ifndef OPENSSL_NO_DH #include +#endif #include -#include +#include #include +#include #ifdef __cplusplus extern "C" { #endif +/* Fixups for missing algorithms */ +#ifdef OPENSSL_NO_RSA +typedef void RSA_METHOD; +#endif +#ifdef OPENSSL_NO_DSA +typedef void DSA_METHOD; +#endif +#ifdef OPENSSL_NO_DH +typedef void DH_METHOD; +#endif + /* These flags are used to control combinations of algorithm (methods) * by bitwise "OR"ing. */ #define ENGINE_METHOD_RSA (unsigned int)0x0001 #define ENGINE_METHOD_DSA (unsigned int)0x0002 #define ENGINE_METHOD_DH (unsigned int)0x0004 #define ENGINE_METHOD_RAND (unsigned int)0x0008 -#define ENGINE_METHOD_BN_MOD_EXP (unsigned int)0x0010 -#define ENGINE_METHOD_BN_MOD_EXP_CRT (unsigned int)0x0020 +#define ENGINE_METHOD_CIPHERS (unsigned int)0x0040 +#define ENGINE_METHOD_DIGESTS (unsigned int)0x0080 /* Obvious all-or-nothing cases. */ #define ENGINE_METHOD_ALL (unsigned int)0xFFFF #define ENGINE_METHOD_NONE (unsigned int)0x0000 +/* This(ese) flag(s) controls behaviour of the ENGINE_TABLE mechanism used + * internally to control registration of ENGINE implementations, and can be set + * by ENGINE_set_table_flags(). The "NOINIT" flag prevents attempts to + * initialise registered ENGINEs if they are not already initialised. */ +#define ENGINE_TABLE_FLAG_NOINIT (unsigned int)0x0001 + +/* ENGINE flags that can be set by ENGINE_set_flags(). */ +/* #define ENGINE_FLAGS_MALLOCED 0x0001 */ /* Not used */ + +/* This flag is for ENGINEs that wish to handle the various 'CMD'-related + * control commands on their own. Without this flag, ENGINE_ctrl() handles these + * control commands on behalf of the ENGINE using their "cmd_defns" data. */ +#define ENGINE_FLAGS_MANUAL_CMD_CTRL (int)0x0002 + +/* This flag is for ENGINEs who return new duplicate structures when found via + * "ENGINE_by_id()". When an ENGINE must store state (eg. if ENGINE_ctrl() + * commands are called in sequence as part of some stateful process like + * key-generation setup and execution), it can set this flag - then each attempt + * to obtain the ENGINE will result in it being copied into a new structure. + * Normally, ENGINEs don't declare this flag so ENGINE_by_id() just increments + * the existing ENGINE's structural reference count. */ +#define ENGINE_FLAGS_BY_ID_COPY (int)0x0004 + +/* ENGINEs can support their own command types, and these flags are used in + * ENGINE_CTRL_GET_CMD_FLAGS to indicate to the caller what kind of input each + * command expects. Currently only numeric and string input is supported. If a + * control command supports none of the _NUMERIC, _STRING, or _NO_INPUT options, + * then it is regarded as an "internal" control command - and not for use in + * config setting situations. As such, they're not available to the + * ENGINE_ctrl_cmd_string() function, only raw ENGINE_ctrl() access. Changes to + * this list of 'command types' should be reflected carefully in + * ENGINE_cmd_is_executable() and ENGINE_ctrl_cmd_string(). */ + +/* accepts a 'long' input value (3rd parameter to ENGINE_ctrl) */ +#define ENGINE_CMD_FLAG_NUMERIC (unsigned int)0x0001 +/* accepts string input (cast from 'void*' to 'const char *', 4th parameter to + * ENGINE_ctrl) */ +#define ENGINE_CMD_FLAG_STRING (unsigned int)0x0002 +/* Indicates that the control command takes *no* input. Ie. the control command + * is unparameterised. */ +#define ENGINE_CMD_FLAG_NO_INPUT (unsigned int)0x0004 +/* Indicates that the control command is internal. This control command won't + * be shown in any output, and is only usable through the ENGINE_ctrl_cmd() + * function. */ +#define ENGINE_CMD_FLAG_INTERNAL (unsigned int)0x0008 + +/* NB: These 3 control commands are deprecated and should not be used. ENGINEs + * relying on these commands should compile conditional support for + * compatibility (eg. if these symbols are defined) but should also migrate the + * same functionality to their own ENGINE-specific control functions that can be + * "discovered" by calling applications. The fact these control commands + * wouldn't be "executable" (ie. usable by text-based config) doesn't change the + * fact that application code can find and use them without requiring per-ENGINE + * hacking. */ + /* These flags are used to tell the ctrl function what should be done. * All command numbers are shared between all engines, even if some don't * make sense to some engines. In such a case, they do nothing but return * the error ENGINE_R_CTRL_COMMAND_NOT_IMPLEMENTED. */ #define ENGINE_CTRL_SET_LOGSTREAM 1 #define ENGINE_CTRL_SET_PASSWORD_CALLBACK 2 +#define ENGINE_CTRL_HUP 3 /* Close and reinitialise any + handles/connections etc. */ +#define ENGINE_CTRL_SET_USER_INTERFACE 4 /* Alternative to callback */ +#define ENGINE_CTRL_SET_CALLBACK_DATA 5 /* User-specific data, used + when calling the password + callback and the user + interface */ + +/* These control commands allow an application to deal with an arbitrary engine + * in a dynamic way. Warn: Negative return values indicate errors FOR THESE + * COMMANDS because zero is used to indicate 'end-of-list'. Other commands, + * including ENGINE-specific command types, return zero for an error. + * + * An ENGINE can choose to implement these ctrl functions, and can internally + * manage things however it chooses - it does so by setting the + * ENGINE_FLAGS_MANUAL_CMD_CTRL flag (using ENGINE_set_flags()). Otherwise the + * ENGINE_ctrl() code handles this on the ENGINE's behalf using the cmd_defns + * data (set using ENGINE_set_cmd_defns()). This means an ENGINE's ctrl() + * handler need only implement its own commands - the above "meta" commands will + * be taken care of. */ + +/* Returns non-zero if the supplied ENGINE has a ctrl() handler. If "not", then + * all the remaining control commands will return failure, so it is worth + * checking this first if the caller is trying to "discover" the engine's + * capabilities and doesn't want errors generated unnecessarily. */ +#define ENGINE_CTRL_HAS_CTRL_FUNCTION 10 +/* Returns a positive command number for the first command supported by the + * engine. Returns zero if no ctrl commands are supported. */ +#define ENGINE_CTRL_GET_FIRST_CMD_TYPE 11 +/* The 'long' argument specifies a command implemented by the engine, and the + * return value is the next command supported, or zero if there are no more. */ +#define ENGINE_CTRL_GET_NEXT_CMD_TYPE 12 +/* The 'void*' argument is a command name (cast from 'const char *'), and the + * return value is the command that corresponds to it. */ +#define ENGINE_CTRL_GET_CMD_FROM_NAME 13 +/* The next two allow a command to be converted into its corresponding string + * form. In each case, the 'long' argument supplies the command. In the NAME_LEN + * case, the return value is the length of the command name (not counting a + * trailing EOL). In the NAME case, the 'void*' argument must be a string buffer + * large enough, and it will be populated with the name of the command (WITH a + * trailing EOL). */ +#define ENGINE_CTRL_GET_NAME_LEN_FROM_CMD 14 +#define ENGINE_CTRL_GET_NAME_FROM_CMD 15 +/* The next two are similar but give a "short description" of a command. */ +#define ENGINE_CTRL_GET_DESC_LEN_FROM_CMD 16 +#define ENGINE_CTRL_GET_DESC_FROM_CMD 17 +/* With this command, the return value is the OR'd combination of + * ENGINE_CMD_FLAG_*** values that indicate what kind of input a given + * engine-specific ctrl command expects. */ +#define ENGINE_CTRL_GET_CMD_FLAGS 18 + +/* ENGINE implementations should start the numbering of their own control + * commands from this value. (ie. ENGINE_CMD_BASE, ENGINE_CMD_BASE + 1, etc). */ +#define ENGINE_CMD_BASE 200 + +/* NB: These 2 nCipher "chil" control commands are deprecated, and their + * functionality is now available through ENGINE-specific control commands + * (exposed through the above-mentioned 'CMD'-handling). Code using these 2 + * commands should be migrated to the more general command handling before these + * are removed. */ + /* Flags specific to the nCipher "chil" engine */ #define ENGINE_CTRL_CHIL_SET_FORKCHECK 100 /* Depending on the value of the (long)i argument, this sets or @@ -99,45 +234,55 @@ extern "C" { /* This prevents the initialisation function from providing mutex * callbacks to the nCipher library. */ -/* As we're missing a BIGNUM_METHOD, we need a couple of locally - * defined function types that engines can implement. */ - -#ifndef HEADER_ENGINE_INT_H -/* mod_exp operation, calculates; r = a ^ p mod m - * NB: ctx can be NULL, but if supplied, the implementation may use - * it if it wishes. */ -typedef int (*BN_MOD_EXP)(BIGNUM *r, BIGNUM *a, const BIGNUM *p, - const BIGNUM *m, BN_CTX *ctx); - -/* private key operation for RSA, provided seperately in case other - * RSA implementations wish to use it. */ -typedef int (*BN_MOD_EXP_CRT)(BIGNUM *r, BIGNUM *a, const BIGNUM *p, - const BIGNUM *q, const BIGNUM *dmp1, const BIGNUM *dmq1, - const BIGNUM *iqmp, BN_CTX *ctx); +/* If an ENGINE supports its own specific control commands and wishes the + * framework to handle the above 'ENGINE_CMD_***'-manipulation commands on its + * behalf, it should supply a null-terminated array of ENGINE_CMD_DEFN entries + * to ENGINE_set_cmd_defns(). It should also implement a ctrl() handler that + * supports the stated commands (ie. the "cmd_num" entries as described by the + * array). NB: The array must be ordered in increasing order of cmd_num. + * "null-terminated" means that the last ENGINE_CMD_DEFN element has cmd_num set + * to zero and/or cmd_name set to NULL. */ +typedef struct ENGINE_CMD_DEFN_st + { + unsigned int cmd_num; /* The command number */ + const char *cmd_name; /* The command name itself */ + const char *cmd_desc; /* A short description of the command */ + unsigned int cmd_flags; /* The input the command expects */ + } ENGINE_CMD_DEFN; /* Generic function pointer */ -typedef void (*ENGINE_GEN_FUNC_PTR)(); +typedef int (*ENGINE_GEN_FUNC_PTR)(); /* Generic function pointer taking no arguments */ -typedef void (*ENGINE_GEN_INT_FUNC_PTR)(void); +typedef int (*ENGINE_GEN_INT_FUNC_PTR)(ENGINE *); /* Specific control function pointer */ -typedef int (*ENGINE_CTRL_FUNC_PTR)(int cmd, long i, void *p, void (*f)()); - -/* The list of "engine" types is a static array of (const ENGINE*) - * pointers (not dynamic because static is fine for now and we otherwise - * have to hook an appropriate load/unload function in to initialise and - * cleanup). */ -typedef struct engine_st ENGINE; -#endif +typedef int (*ENGINE_CTRL_FUNC_PTR)(ENGINE *, int, long, void *, void (*f)()); +/* Generic load_key function pointer */ +typedef EVP_PKEY * (*ENGINE_LOAD_KEY_PTR)(ENGINE *, const char *, + UI_METHOD *ui_method, void *callback_data); +/* These callback types are for an ENGINE's handler for cipher and digest logic. + * These handlers have these prototypes; + * int foo(ENGINE *e, const EVP_CIPHER **cipher, const int **nids, int nid); + * int foo(ENGINE *e, const EVP_MD **digest, const int **nids, int nid); + * Looking at how to implement these handlers in the case of cipher support, if + * the framework wants the EVP_CIPHER for 'nid', it will call; + * foo(e, &p_evp_cipher, NULL, nid); (return zero for failure) + * If the framework wants a list of supported 'nid's, it will call; + * foo(e, NULL, &p_nids, 0); (returns number of 'nids' or -1 for error) + */ +/* Returns to a pointer to the array of supported cipher 'nid's. If the second + * parameter is non-NULL it is set to the size of the returned array. */ +typedef int (*ENGINE_CIPHERS_PTR)(ENGINE *, const EVP_CIPHER **, const int **, int); +typedef int (*ENGINE_DIGESTS_PTR)(ENGINE *, const EVP_MD **, const int **, int); -/* STRUCTURE functions ... all of these functions deal with pointers to - * ENGINE structures where the pointers have a "structural reference". - * This means that their reference is to allow access to the structure - * but it does not imply that the structure is functional. To simply - * increment or decrement the structural reference count, use ENGINE_new - * and ENGINE_free. NB: This is not required when iterating using - * ENGINE_get_next as it will automatically decrement the structural - * reference count of the "current" ENGINE and increment the structural - * reference count of the ENGINE it returns (unless it is NULL). */ +/* STRUCTURE functions ... all of these functions deal with pointers to ENGINE + * structures where the pointers have a "structural reference". This means that + * their reference is to allowed access to the structure but it does not imply + * that the structure is functional. To simply increment or decrement the + * structural reference count, use ENGINE_by_id and ENGINE_free. NB: This is not + * required when iterating using ENGINE_get_next as it will automatically + * decrement the structural reference count of the "current" ENGINE and + * increment the structural reference count of the ENGINE it returns (unless it + * is NULL). */ /* Get the first/last "ENGINE" type available. */ ENGINE *ENGINE_get_first(void); @@ -151,67 +296,167 @@ int ENGINE_add(ENGINE *e); int ENGINE_remove(ENGINE *e); /* Retrieve an engine from the list by its unique "id" value. */ ENGINE *ENGINE_by_id(const char *id); +/* Add all the built-in engines. */ +void ENGINE_load_openssl(void); +void ENGINE_load_dynamic(void); +void ENGINE_load_cswift(void); +void ENGINE_load_chil(void); +void ENGINE_load_atalla(void); +void ENGINE_load_nuron(void); +void ENGINE_load_ubsec(void); +void ENGINE_load_aep(void); +void ENGINE_load_sureware(void); +void ENGINE_load_4758cca(void); +void ENGINE_load_openbsd_dev_crypto(void); +void ENGINE_load_builtin_engines(void); -/* These functions are useful for manufacturing new ENGINE - * structures. They don't address reference counting at all - - * one uses them to populate an ENGINE structure with personalised - * implementations of things prior to using it directly or adding - * it to the builtin ENGINE list in OpenSSL. These are also here - * so that the ENGINE structure doesn't have to be exposed and - * break binary compatibility! - * - * NB: I'm changing ENGINE_new to force the ENGINE structure to - * be allocated from within OpenSSL. See the comment for - * ENGINE_get_struct_size(). - */ -#if 0 -ENGINE *ENGINE_new(ENGINE *e); -#else +/* Get and set global flags (ENGINE_TABLE_FLAG_***) for the implementation + * "registry" handling. */ +unsigned int ENGINE_get_table_flags(void); +void ENGINE_set_table_flags(unsigned int flags); + +/* Manage registration of ENGINEs per "table". For each type, there are 3 + * functions; + * ENGINE_register_***(e) - registers the implementation from 'e' (if it has one) + * ENGINE_unregister_***(e) - unregister the implementation from 'e' + * ENGINE_register_all_***() - call ENGINE_register_***() for each 'e' in the list + * Cleanup is automatically registered from each table when required, so + * ENGINE_cleanup() will reverse any "register" operations. */ + +int ENGINE_register_RSA(ENGINE *e); +void ENGINE_unregister_RSA(ENGINE *e); +void ENGINE_register_all_RSA(void); + +int ENGINE_register_DSA(ENGINE *e); +void ENGINE_unregister_DSA(ENGINE *e); +void ENGINE_register_all_DSA(void); + +int ENGINE_register_DH(ENGINE *e); +void ENGINE_unregister_DH(ENGINE *e); +void ENGINE_register_all_DH(void); + +int ENGINE_register_RAND(ENGINE *e); +void ENGINE_unregister_RAND(ENGINE *e); +void ENGINE_register_all_RAND(void); + +int ENGINE_register_ciphers(ENGINE *e); +void ENGINE_unregister_ciphers(ENGINE *e); +void ENGINE_register_all_ciphers(void); + +int ENGINE_register_digests(ENGINE *e); +void ENGINE_unregister_digests(ENGINE *e); +void ENGINE_register_all_digests(void); + +/* These functions register all support from the above categories. Note, use of + * these functions can result in static linkage of code your application may not + * need. If you only need a subset of functionality, consider using more + * selective initialisation. */ +int ENGINE_register_complete(ENGINE *e); +int ENGINE_register_all_complete(void); + +/* Send parametrised control commands to the engine. The possibilities to send + * down an integer, a pointer to data or a function pointer are provided. Any of + * the parameters may or may not be NULL, depending on the command number. In + * actuality, this function only requires a structural (rather than functional) + * reference to an engine, but many control commands may require the engine be + * functional. The caller should be aware of trying commands that require an + * operational ENGINE, and only use functional references in such situations. */ +int ENGINE_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)()); + +/* This function tests if an ENGINE-specific command is usable as a "setting". + * Eg. in an application's config file that gets processed through + * ENGINE_ctrl_cmd_string(). If this returns zero, it is not available to + * ENGINE_ctrl_cmd_string(), only ENGINE_ctrl(). */ +int ENGINE_cmd_is_executable(ENGINE *e, int cmd); + +/* This function works like ENGINE_ctrl() with the exception of taking a + * command name instead of a command number, and can handle optional commands. + * See the comment on ENGINE_ctrl_cmd_string() for an explanation on how to + * use the cmd_name and cmd_optional. */ +int ENGINE_ctrl_cmd(ENGINE *e, const char *cmd_name, + long i, void *p, void (*f)(), int cmd_optional); + +/* This function passes a command-name and argument to an ENGINE. The cmd_name + * is converted to a command number and the control command is called using + * 'arg' as an argument (unless the ENGINE doesn't support such a command, in + * which case no control command is called). The command is checked for input + * flags, and if necessary the argument will be converted to a numeric value. If + * cmd_optional is non-zero, then if the ENGINE doesn't support the given + * cmd_name the return value will be success anyway. This function is intended + * for applications to use so that users (or config files) can supply + * engine-specific config data to the ENGINE at run-time to control behaviour of + * specific engines. As such, it shouldn't be used for calling ENGINE_ctrl() + * functions that return data, deal with binary data, or that are otherwise + * supposed to be used directly through ENGINE_ctrl() in application code. Any + * "return" data from an ENGINE_ctrl() operation in this function will be lost - + * the return value is interpreted as failure if the return value is zero, + * success otherwise, and this function returns a boolean value as a result. In + * other words, vendors of 'ENGINE'-enabled devices should write ENGINE + * implementations with parameterisations that work in this scheme, so that + * compliant ENGINE-based applications can work consistently with the same + * configuration for the same ENGINE-enabled devices, across applications. */ +int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char *arg, + int cmd_optional); + +/* These functions are useful for manufacturing new ENGINE structures. They + * don't address reference counting at all - one uses them to populate an ENGINE + * structure with personalised implementations of things prior to using it + * directly or adding it to the builtin ENGINE list in OpenSSL. These are also + * here so that the ENGINE structure doesn't have to be exposed and break binary + * compatibility! */ ENGINE *ENGINE_new(void); -#endif int ENGINE_free(ENGINE *e); int ENGINE_set_id(ENGINE *e, const char *id); int ENGINE_set_name(ENGINE *e, const char *name); -int ENGINE_set_RSA(ENGINE *e, RSA_METHOD *rsa_meth); -int ENGINE_set_DSA(ENGINE *e, DSA_METHOD *dsa_meth); -int ENGINE_set_DH(ENGINE *e, DH_METHOD *dh_meth); -int ENGINE_set_RAND(ENGINE *e, RAND_METHOD *rand_meth); -int ENGINE_set_BN_mod_exp(ENGINE *e, BN_MOD_EXP bn_mod_exp); -int ENGINE_set_BN_mod_exp_crt(ENGINE *e, BN_MOD_EXP_CRT bn_mod_exp_crt); +int ENGINE_set_RSA(ENGINE *e, const RSA_METHOD *rsa_meth); +int ENGINE_set_DSA(ENGINE *e, const DSA_METHOD *dsa_meth); +int ENGINE_set_DH(ENGINE *e, const DH_METHOD *dh_meth); +int ENGINE_set_RAND(ENGINE *e, const RAND_METHOD *rand_meth); +int ENGINE_set_destroy_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR destroy_f); int ENGINE_set_init_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR init_f); int ENGINE_set_finish_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR finish_f); int ENGINE_set_ctrl_function(ENGINE *e, ENGINE_CTRL_FUNC_PTR ctrl_f); +int ENGINE_set_load_privkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpriv_f); +int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f); +int ENGINE_set_ciphers(ENGINE *e, ENGINE_CIPHERS_PTR f); +int ENGINE_set_digests(ENGINE *e, ENGINE_DIGESTS_PTR f); +int ENGINE_set_flags(ENGINE *e, int flags); +int ENGINE_set_cmd_defns(ENGINE *e, const ENGINE_CMD_DEFN *defns); +/* These functions (and the "get" function lower down) allow control over any + * per-structure ENGINE data. */ +int ENGINE_get_ex_new_index(long argl, void *argp, CRYPTO_EX_new *new_func, + CRYPTO_EX_dup *dup_func, CRYPTO_EX_free *free_func); +int ENGINE_set_ex_data(ENGINE *e, int idx, void *arg); -/* These return values from within the ENGINE structure. These can - * be useful with functional references as well as structural - * references - it depends which you obtained. Using the result - * for functional purposes if you only obtained a structural - * reference may be problematic! */ -const char *ENGINE_get_id(ENGINE *e); -const char *ENGINE_get_name(ENGINE *e); -RSA_METHOD *ENGINE_get_RSA(ENGINE *e); -DSA_METHOD *ENGINE_get_DSA(ENGINE *e); -DH_METHOD *ENGINE_get_DH(ENGINE *e); -RAND_METHOD *ENGINE_get_RAND(ENGINE *e); -BN_MOD_EXP ENGINE_get_BN_mod_exp(ENGINE *e); -BN_MOD_EXP_CRT ENGINE_get_BN_mod_exp_crt(ENGINE *e); -ENGINE_GEN_INT_FUNC_PTR ENGINE_get_init_function(ENGINE *e); -ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(ENGINE *e); -ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(ENGINE *e); - -/* ENGINE_new is normally passed a NULL in the first parameter because - * the calling code doesn't have access to the definition of the ENGINE - * structure (for good reason). However, if the caller wishes to use - * its own memory allocation or use a static array, the following call - * should be used to check the amount of memory the ENGINE structure - * will occupy. This will make the code more future-proof. - * - * NB: I'm "#if 0"-ing this out because it's better to force the use of - * internally allocated memory. See similar change in ENGINE_new(). - */ -#if 0 -int ENGINE_get_struct_size(void); -#endif +/* This function cleans up anything that needs it. Eg. the ENGINE_add() function + * automatically ensures the list cleanup function is registered to be called + * from ENGINE_cleanup(). Similarly, all ENGINE_register_*** functions ensure + * ENGINE_cleanup() will clean up after them. */ +void ENGINE_cleanup(void); + +/* These return values from within the ENGINE structure. These can be useful + * with functional references as well as structural references - it depends + * which you obtained. Using the result for functional purposes if you only + * obtained a structural reference may be problematic! */ +const char *ENGINE_get_id(const ENGINE *e); +const char *ENGINE_get_name(const ENGINE *e); +const RSA_METHOD *ENGINE_get_RSA(const ENGINE *e); +const DSA_METHOD *ENGINE_get_DSA(const ENGINE *e); +const DH_METHOD *ENGINE_get_DH(const ENGINE *e); +const RAND_METHOD *ENGINE_get_RAND(const ENGINE *e); +ENGINE_GEN_INT_FUNC_PTR ENGINE_get_destroy_function(const ENGINE *e); +ENGINE_GEN_INT_FUNC_PTR ENGINE_get_init_function(const ENGINE *e); +ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(const ENGINE *e); +ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(const ENGINE *e); +ENGINE_LOAD_KEY_PTR ENGINE_get_load_privkey_function(const ENGINE *e); +ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e); +ENGINE_CIPHERS_PTR ENGINE_get_ciphers(const ENGINE *e); +ENGINE_DIGESTS_PTR ENGINE_get_digests(const ENGINE *e); +const EVP_CIPHER *ENGINE_get_cipher(ENGINE *e, int nid); +const EVP_MD *ENGINE_get_digest(ENGINE *e, int nid); +const ENGINE_CMD_DEFN *ENGINE_get_cmd_defns(const ENGINE *e); +int ENGINE_get_flags(const ENGINE *e); +void *ENGINE_get_ex_data(const ENGINE *e, int idx); /* FUNCTIONAL functions. These functions deal with ENGINE structures * that have (or will) be initialised for use. Broadly speaking, the @@ -233,20 +478,14 @@ int ENGINE_init(ENGINE *e); * a corresponding call to ENGINE_free as it also releases a structural * reference. */ int ENGINE_finish(ENGINE *e); -/* Send control parametrised commands to the engine. The possibilities - * to send down an integer, a pointer to data or a function pointer are - * provided. Any of the parameters may or may not be NULL, depending - * on the command number */ -/* WARNING: This is currently experimental and may change radically! */ -int ENGINE_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)()); /* The following functions handle keys that are stored in some secondary * location, handled by the engine. The storage may be on a card or * whatever. */ EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id, - const char *passphrase); + UI_METHOD *ui_method, void *callback_data); EVP_PKEY *ENGINE_load_public_key(ENGINE *e, const char *key_id, - const char *passphrase); + UI_METHOD *ui_method, void *callback_data); /* This returns a pointer for the current ENGINE structure that * is (by default) performing any RSA operations. The value returned @@ -257,117 +496,192 @@ ENGINE *ENGINE_get_default_RSA(void); ENGINE *ENGINE_get_default_DSA(void); ENGINE *ENGINE_get_default_DH(void); ENGINE *ENGINE_get_default_RAND(void); -ENGINE *ENGINE_get_default_BN_mod_exp(void); -ENGINE *ENGINE_get_default_BN_mod_exp_crt(void); +/* These functions can be used to get a functional reference to perform + * ciphering or digesting corresponding to "nid". */ +ENGINE *ENGINE_get_cipher_engine(int nid); +ENGINE *ENGINE_get_digest_engine(int nid); /* This sets a new default ENGINE structure for performing RSA * operations. If the result is non-zero (success) then the ENGINE * structure will have had its reference count up'd so the caller * should still free their own reference 'e'. */ int ENGINE_set_default_RSA(ENGINE *e); +int ENGINE_set_default_string(ENGINE *e, const char *list); /* Same for the other "methods" */ int ENGINE_set_default_DSA(ENGINE *e); int ENGINE_set_default_DH(ENGINE *e); int ENGINE_set_default_RAND(ENGINE *e); -int ENGINE_set_default_BN_mod_exp(ENGINE *e); -int ENGINE_set_default_BN_mod_exp_crt(ENGINE *e); +int ENGINE_set_default_ciphers(ENGINE *e); +int ENGINE_set_default_digests(ENGINE *e); /* The combination "set" - the flags are bitwise "OR"d from the - * ENGINE_METHOD_*** defines above. */ + * ENGINE_METHOD_*** defines above. As with the "ENGINE_register_complete()" + * function, this function can result in unnecessary static linkage. If your + * application requires only specific functionality, consider using more + * selective functions. */ int ENGINE_set_default(ENGINE *e, unsigned int flags); -/* Obligatory error function. */ -void ERR_load_ENGINE_strings(void); +void ENGINE_add_conf_module(void); -/* - * Error codes for all engine functions. NB: We use "generic" - * function names instead of per-implementation ones because this - * levels the playing field for externally implemented bootstrapped - * support code. As the filename and line number is included, it's - * more important to indicate the type of function, so that - * bootstrapped code (that can't easily add its own errors in) can - * use the same error codes too. - */ +/* Deprecated functions ... */ +/* int ENGINE_clear_defaults(void); */ + +/**************************/ +/* DYNAMIC ENGINE SUPPORT */ +/**************************/ + +/* Binary/behaviour compatibility levels */ +#define OSSL_DYNAMIC_VERSION (unsigned long)0x00010100 +/* Binary versions older than this are too old for us (whether we're a loader or + * a loadee) */ +#define OSSL_DYNAMIC_OLDEST (unsigned long)0x00010100 + +/* When compiling an ENGINE entirely as an external shared library, loadable by + * the "dynamic" ENGINE, these types are needed. The 'dynamic_fns' structure + * type provides the calling application's (or library's) error functionality + * and memory management function pointers to the loaded library. These should + * be used/set in the loaded library code so that the loading application's + * 'state' will be used/changed in all operations. */ +typedef void *(*dyn_MEM_malloc_cb)(size_t); +typedef void *(*dyn_MEM_realloc_cb)(void *, size_t); +typedef void (*dyn_MEM_free_cb)(void *); +typedef struct st_dynamic_MEM_fns { + dyn_MEM_malloc_cb malloc_cb; + dyn_MEM_realloc_cb realloc_cb; + dyn_MEM_free_cb free_cb; + } dynamic_MEM_fns; +/* FIXME: Perhaps the memory and locking code (crypto.h) should declare and use + * these types so we (and any other dependant code) can simplify a bit?? */ +typedef void (*dyn_lock_locking_cb)(int,int,const char *,int); +typedef int (*dyn_lock_add_lock_cb)(int*,int,int,const char *,int); +typedef struct CRYPTO_dynlock_value *(*dyn_dynlock_create_cb)( + const char *,int); +typedef void (*dyn_dynlock_lock_cb)(int,struct CRYPTO_dynlock_value *, + const char *,int); +typedef void (*dyn_dynlock_destroy_cb)(struct CRYPTO_dynlock_value *, + const char *,int); +typedef struct st_dynamic_LOCK_fns { + dyn_lock_locking_cb lock_locking_cb; + dyn_lock_add_lock_cb lock_add_lock_cb; + dyn_dynlock_create_cb dynlock_create_cb; + dyn_dynlock_lock_cb dynlock_lock_cb; + dyn_dynlock_destroy_cb dynlock_destroy_cb; + } dynamic_LOCK_fns; +/* The top-level structure */ +typedef struct st_dynamic_fns { + const ERR_FNS *err_fns; + const CRYPTO_EX_DATA_IMPL *ex_data_fns; + dynamic_MEM_fns mem_fns; + dynamic_LOCK_fns lock_fns; + } dynamic_fns; + +/* The version checking function should be of this prototype. NB: The + * ossl_version value passed in is the OSSL_DYNAMIC_VERSION of the loading code. + * If this function returns zero, it indicates a (potential) version + * incompatibility and the loaded library doesn't believe it can proceed. + * Otherwise, the returned value is the (latest) version supported by the + * loading library. The loader may still decide that the loaded code's version + * is unsatisfactory and could veto the load. The function is expected to + * be implemented with the symbol name "v_check", and a default implementation + * can be fully instantiated with IMPLEMENT_DYNAMIC_CHECK_FN(). */ +typedef unsigned long (*dynamic_v_check_fn)(unsigned long ossl_version); +#define IMPLEMENT_DYNAMIC_CHECK_FN() \ + unsigned long v_check(unsigned long v) { \ + if(v >= OSSL_DYNAMIC_OLDEST) return OSSL_DYNAMIC_VERSION; \ + return 0; } + +/* This function is passed the ENGINE structure to initialise with its own + * function and command settings. It should not adjust the structural or + * functional reference counts. If this function returns zero, (a) the load will + * be aborted, (b) the previous ENGINE state will be memcpy'd back onto the + * structure, and (c) the shared library will be unloaded. So implementations + * should do their own internal cleanup in failure circumstances otherwise they + * could leak. The 'id' parameter, if non-NULL, represents the ENGINE id that + * the loader is looking for. If this is NULL, the shared library can choose to + * return failure or to initialise a 'default' ENGINE. If non-NULL, the shared + * library must initialise only an ENGINE matching the passed 'id'. The function + * is expected to be implemented with the symbol name "bind_engine". A standard + * implementation can be instantiated with IMPLEMENT_DYNAMIC_BIND_FN(fn) where + * the parameter 'fn' is a callback function that populates the ENGINE structure + * and returns an int value (zero for failure). 'fn' should have prototype; + * [static] int fn(ENGINE *e, const char *id); */ +typedef int (*dynamic_bind_engine)(ENGINE *e, const char *id, + const dynamic_fns *fns); +#define IMPLEMENT_DYNAMIC_BIND_FN(fn) \ + int bind_engine(ENGINE *e, const char *id, const dynamic_fns *fns) { \ + if(!CRYPTO_set_mem_functions(fns->mem_fns.malloc_cb, \ + fns->mem_fns.realloc_cb, fns->mem_fns.free_cb)) \ + return 0; \ + CRYPTO_set_locking_callback(fns->lock_fns.lock_locking_cb); \ + CRYPTO_set_add_lock_callback(fns->lock_fns.lock_add_lock_cb); \ + CRYPTO_set_dynlock_create_callback(fns->lock_fns.dynlock_create_cb); \ + CRYPTO_set_dynlock_lock_callback(fns->lock_fns.dynlock_lock_cb); \ + CRYPTO_set_dynlock_destroy_callback(fns->lock_fns.dynlock_destroy_cb); \ + if(!CRYPTO_set_ex_data_implementation(fns->ex_data_fns)) \ + return 0; \ + if(!ERR_set_implementation(fns->err_fns)) return 0; \ + if(!fn(e,id)) return 0; \ + return 1; } /* BEGIN ERROR CODES */ /* The following lines are auto generated by the script mkerr.pl. Any changes * made after this point may be overwritten when the script is next run. */ +void ERR_load_ENGINE_strings(void); /* Error codes for the ENGINE functions. */ /* Function codes. */ -#define ENGINE_F_ATALLA_FINISH 135 -#define ENGINE_F_ATALLA_INIT 136 -#define ENGINE_F_ATALLA_MOD_EXP 137 -#define ENGINE_F_ATALLA_RSA_MOD_EXP 138 -#define ENGINE_F_CSWIFT_DSA_SIGN 133 -#define ENGINE_F_CSWIFT_DSA_VERIFY 134 -#define ENGINE_F_CSWIFT_FINISH 100 -#define ENGINE_F_CSWIFT_INIT 101 -#define ENGINE_F_CSWIFT_MOD_EXP 102 -#define ENGINE_F_CSWIFT_MOD_EXP_CRT 103 -#define ENGINE_F_CSWIFT_RSA_MOD_EXP 104 +#define ENGINE_F_DYNAMIC_CTRL 180 +#define ENGINE_F_DYNAMIC_GET_DATA_CTX 181 +#define ENGINE_F_DYNAMIC_LOAD 182 #define ENGINE_F_ENGINE_ADD 105 #define ENGINE_F_ENGINE_BY_ID 106 +#define ENGINE_F_ENGINE_CMD_IS_EXECUTABLE 170 #define ENGINE_F_ENGINE_CTRL 142 +#define ENGINE_F_ENGINE_CTRL_CMD 178 +#define ENGINE_F_ENGINE_CTRL_CMD_STRING 171 #define ENGINE_F_ENGINE_FINISH 107 #define ENGINE_F_ENGINE_FREE 108 -#define ENGINE_F_ENGINE_GET_BN_MOD_EXP 109 -#define ENGINE_F_ENGINE_GET_BN_MOD_EXP_CRT 110 -#define ENGINE_F_ENGINE_GET_CTRL_FUNCTION 144 -#define ENGINE_F_ENGINE_GET_DH 111 -#define ENGINE_F_ENGINE_GET_DSA 112 -#define ENGINE_F_ENGINE_GET_FINISH_FUNCTION 145 -#define ENGINE_F_ENGINE_GET_ID 113 -#define ENGINE_F_ENGINE_GET_INIT_FUNCTION 146 -#define ENGINE_F_ENGINE_GET_NAME 114 +#define ENGINE_F_ENGINE_GET_CIPHER 185 +#define ENGINE_F_ENGINE_GET_DEFAULT_TYPE 177 +#define ENGINE_F_ENGINE_GET_DIGEST 186 #define ENGINE_F_ENGINE_GET_NEXT 115 #define ENGINE_F_ENGINE_GET_PREV 116 -#define ENGINE_F_ENGINE_GET_RAND 117 -#define ENGINE_F_ENGINE_GET_RSA 118 #define ENGINE_F_ENGINE_INIT 119 #define ENGINE_F_ENGINE_LIST_ADD 120 #define ENGINE_F_ENGINE_LIST_REMOVE 121 #define ENGINE_F_ENGINE_LOAD_PRIVATE_KEY 150 #define ENGINE_F_ENGINE_LOAD_PUBLIC_KEY 151 +#define ENGINE_F_ENGINE_MODULE_INIT 187 #define ENGINE_F_ENGINE_NEW 122 #define ENGINE_F_ENGINE_REMOVE 123 -#define ENGINE_F_ENGINE_SET_BN_MOD_EXP 124 -#define ENGINE_F_ENGINE_SET_BN_MOD_EXP_CRT 125 -#define ENGINE_F_ENGINE_SET_CTRL_FUNCTION 147 +#define ENGINE_F_ENGINE_SET_DEFAULT_STRING 189 #define ENGINE_F_ENGINE_SET_DEFAULT_TYPE 126 -#define ENGINE_F_ENGINE_SET_DH 127 -#define ENGINE_F_ENGINE_SET_DSA 128 -#define ENGINE_F_ENGINE_SET_FINISH_FUNCTION 148 #define ENGINE_F_ENGINE_SET_ID 129 -#define ENGINE_F_ENGINE_SET_INIT_FUNCTION 149 #define ENGINE_F_ENGINE_SET_NAME 130 -#define ENGINE_F_ENGINE_SET_RAND 131 -#define ENGINE_F_ENGINE_SET_RSA 132 +#define ENGINE_F_ENGINE_TABLE_REGISTER 184 #define ENGINE_F_ENGINE_UNLOAD_KEY 152 -#define ENGINE_F_HWCRHK_CTRL 143 -#define ENGINE_F_HWCRHK_FINISH 135 -#define ENGINE_F_HWCRHK_GET_PASS 155 -#define ENGINE_F_HWCRHK_INIT 136 -#define ENGINE_F_HWCRHK_LOAD_PRIVKEY 153 -#define ENGINE_F_HWCRHK_LOAD_PUBKEY 154 -#define ENGINE_F_HWCRHK_MOD_EXP 137 -#define ENGINE_F_HWCRHK_MOD_EXP_CRT 138 -#define ENGINE_F_HWCRHK_RAND_BYTES 139 -#define ENGINE_F_HWCRHK_RSA_MOD_EXP 140 +#define ENGINE_F_INT_CTRL_HELPER 172 +#define ENGINE_F_INT_ENGINE_CONFIGURE 188 #define ENGINE_F_LOG_MESSAGE 141 +#define ENGINE_F_SET_DATA_CTX 183 /* Reason codes. */ #define ENGINE_R_ALREADY_LOADED 100 -#define ENGINE_R_BIO_WAS_FREED 121 -#define ENGINE_R_BN_CTX_FULL 101 -#define ENGINE_R_BN_EXPAND_FAIL 102 -#define ENGINE_R_CHIL_ERROR 123 +#define ENGINE_R_ARGUMENT_IS_NOT_A_NUMBER 133 +#define ENGINE_R_CMD_NOT_EXECUTABLE 134 +#define ENGINE_R_COMMAND_TAKES_INPUT 135 +#define ENGINE_R_COMMAND_TAKES_NO_INPUT 136 #define ENGINE_R_CONFLICTING_ENGINE_ID 103 #define ENGINE_R_CTRL_COMMAND_NOT_IMPLEMENTED 119 +#define ENGINE_R_DH_NOT_IMPLEMENTED 139 +#define ENGINE_R_DSA_NOT_IMPLEMENTED 140 #define ENGINE_R_DSO_FAILURE 104 +#define ENGINE_R_DSO_NOT_FOUND 132 +#define ENGINE_R_ENGINES_SECTION_ERROR 148 #define ENGINE_R_ENGINE_IS_NOT_IN_LIST 105 +#define ENGINE_R_ENGINE_SECTION_ERROR 149 #define ENGINE_R_FAILED_LOADING_PRIVATE_KEY 128 #define ENGINE_R_FAILED_LOADING_PUBLIC_KEY 129 #define ENGINE_R_FINISH_FAILED 106 @@ -375,24 +689,26 @@ void ERR_load_ENGINE_strings(void); #define ENGINE_R_ID_OR_NAME_MISSING 108 #define ENGINE_R_INIT_FAILED 109 #define ENGINE_R_INTERNAL_LIST_ERROR 110 -#define ENGINE_R_MISSING_KEY_COMPONENTS 111 +#define ENGINE_R_INVALID_ARGUMENT 143 +#define ENGINE_R_INVALID_CMD_NAME 137 +#define ENGINE_R_INVALID_CMD_NUMBER 138 +#define ENGINE_R_INVALID_INIT_VALUE 151 +#define ENGINE_R_INVALID_STRING 150 #define ENGINE_R_NOT_INITIALISED 117 #define ENGINE_R_NOT_LOADED 112 -#define ENGINE_R_NO_CALLBACK 127 #define ENGINE_R_NO_CONTROL_FUNCTION 120 -#define ENGINE_R_NO_KEY 124 +#define ENGINE_R_NO_INDEX 144 #define ENGINE_R_NO_LOAD_FUNCTION 125 #define ENGINE_R_NO_REFERENCE 130 #define ENGINE_R_NO_SUCH_ENGINE 116 #define ENGINE_R_NO_UNLOAD_FUNCTION 126 #define ENGINE_R_PROVIDE_PARAMETERS 113 -#define ENGINE_R_REQUEST_FAILED 114 -#define ENGINE_R_REQUEST_FALLBACK 118 -#define ENGINE_R_SIZE_TOO_LARGE_OR_TOO_SMALL 122 -#define ENGINE_R_UNIT_FAILURE 115 +#define ENGINE_R_RSA_NOT_IMPLEMENTED 141 +#define ENGINE_R_UNIMPLEMENTED_CIPHER 146 +#define ENGINE_R_UNIMPLEMENTED_DIGEST 147 +#define ENGINE_R_VERSION_INCOMPATIBILITY 145 #ifdef __cplusplus } #endif #endif - -- cgit v1.2.3-55-g6feb