mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-21 06:09:35 +08:00
Code Issues Packages Projects Releases Wiki Activity
af3e7e1bcc
openssl/crypto/provider_core.c

896 lines
27 KiB
C
Raw Normal View History

Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/*
* Copyright 2019 The OpenSSL Project Authors. All Rights Reserved.
*
* Licensed under the Apache License 2.0 (the "License"). You may not use
* this file except in compliance with the License. You can obtain a copy
* in the file LICENSE in the source distribution or at
* https://www.openssl.org/source/license.html
*/
#include <openssl/core.h>
#include <openssl/core_numbers.h>
Add fips provider code for handling self test data More PR's related to self test will be derived from this PR. Note: the code removed in core_get_params() was causing a freeze since the fips module was being loaded from a config file, which then called core_get_params() which then tried to init the config fle again... Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9596)
2019-08-19 07:18:33 +08:00
#include <openssl/core_names.h>
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
#include <openssl/params.h>
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
#include <openssl/opensslv.h>
Reorganize private crypto header files Currently, there are two different directories which contain internal header files of libcrypto which are meant to be shared internally: While header files in 'include/internal' are intended to be shared between libcrypto and libssl, the files in 'crypto/include/internal' are intended to be shared inside libcrypto only. To make things complicated, the include search path is set up in such a way that the directive #include "internal/file.h" could refer to a file in either of these two directoroes. This makes it necessary in some cases to add a '_int.h' suffix to some files to resolve this ambiguity: #include "internal/file.h" # located in 'include/internal' #include "internal/file_int.h" # located in 'crypto/include/internal' This commit moves the private crypto headers from 'crypto/include/internal' to 'include/crypto' As a result, the include directives become unambiguous #include "internal/file.h" # located in 'include/internal' #include "crypto/file.h" # located in 'include/crypto' hence the superfluous '_int.h' suffixes can be stripped. The files 'store_int.h' and 'store.h' need to be treated specially; they are joined into a single file. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9333)
2019-09-28 06:45:33 +08:00
#include "crypto/cryptlib.h"
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
#include "internal/nelem.h"
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
#include "internal/thread_once.h"
#include "internal/provider.h"
#include "internal/refcount.h"
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
#include "provider_local.h"
static OSSL_PROVIDER *provider_new(const char *name,
OSSL_provider_init_fn *init_function);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/*-
* Provider Object structure
* =========================
*/
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
typedef struct {
char *name;
char *value;
} INFOPAIR;
DEFINE_STACK_OF(INFOPAIR)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
struct provider_store_st; /* Forward declaration */
struct ossl_provider_st {
/* Flag bits */
unsigned int flag_initialized:1;
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
unsigned int flag_fallback:1;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/* OpenSSL library side data */
CRYPTO_REF_COUNT refcnt;
crypto/provider_core.c: correct definition and use of lock Fixes #8476 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8477)
2019-03-14 14:59:28 +08:00
CRYPTO_RWLOCK *refcnt_lock; /* For the ref counter */
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
char *name;
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
char *path;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
DSO *module;
OSSL_provider_init_fn *init_function;
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
STACK_OF(INFOPAIR) *parameters;
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
OPENSSL_CTX *libctx; /* The library context this instance is in */
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
struct provider_store_st *store; /* The store this instance belongs to */
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#ifndef FIPS_MODE
/*
* In the FIPS module inner provider, this isn't needed, since the
* error upcalls are always direct calls to the outer provider.
*/
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
int error_lib; /* ERR library number, one for each provider */
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# ifndef OPENSSL_NO_ERR
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
ERR_STRING_DATA *error_strings; /* Copy of what the provider gives us */
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# endif
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/* Provider side functions */
OSSL_provider_teardown_fn *teardown;
Rename provider and core get_param_types functions It was argued that names like SOMETHING_set_param_types were confusing, and a rename has been proposed to SOMETHING_settable_params, and by consequence, SOMETHING_get_param_types is renamed SOMETHING_gettable_params. This changes implements this change for the dispatched provider and core functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9591)
2019-08-15 02:17:39 +08:00
OSSL_provider_gettable_params_fn *gettable_params;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
OSSL_provider_get_params_fn *get_params;
Replumbing: Add support for the provider query_operation function Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:57:28 +08:00
OSSL_provider_query_operation_fn *query_operation;
Replumbing: give the possibility for the provider to create a context OSSL_provider_init() gets another output parameter, holding a pointer to a provider side context. It's entirely up to the provider to define the context and what it's being used for. This pointer is passed back to other provider functions, typically the provider global get_params and set_params functions, and also the diverse algorithm context creators, and of course, the teardown function. With this, a provider can be instantiated more than once, or be re-loaded as the case may be, while maintaining instance state. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8848)
2019-04-30 19:41:51 +08:00
/* Provider side data */
void *provctx;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
};
DEFINE_STACK_OF(OSSL_PROVIDER)
static int ossl_provider_cmp(const OSSL_PROVIDER * const *a,
const OSSL_PROVIDER * const *b)
{
return strcmp((*a)->name, (*b)->name);
}
/*-
* Provider Object store
* =====================
*
* The Provider Object store is a library context object, and therefore needs
* an index.
*/
struct provider_store_st {
STACK_OF(OSSL_PROVIDER) *providers;
CRYPTO_RWLOCK *lock;
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
unsigned int use_fallbacks:1;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
};
static void provider_store_free(void *vstore)
{
struct provider_store_st *store = vstore;
if (store == NULL)
return;
sk_OSSL_PROVIDER_pop_free(store->providers, ossl_provider_free);
CRYPTO_THREAD_lock_free(store->lock);
OPENSSL_free(store);
}
Instead of global data store it in an OPENSSL_CTX Various core and property related code files used global data. We should store all of that in an OPENSSL_CTX instead. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8857)
2019-05-01 18:02:43 +08:00
static void *provider_store_new(OPENSSL_CTX *ctx)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
struct provider_store_st *store = OPENSSL_zalloc(sizeof(*store));
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
const struct predefined_providers_st *p = NULL;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
if (store == NULL
|| (store->providers = sk_OSSL_PROVIDER_new(ossl_provider_cmp)) == NULL
|| (store->lock = CRYPTO_THREAD_lock_new()) == NULL) {
provider_store_free(store);
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
return NULL;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
store->use_fallbacks = 1;
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
for (p = predefined_providers; p->name != NULL; p++) {
OSSL_PROVIDER *prov = NULL;
/*
* We use the internal constructor directly here,
* otherwise we get a call loop
*/
prov = provider_new(p->name, p->init);
if (prov == NULL
|| sk_OSSL_PROVIDER_push(store->providers, prov) == 0) {
ossl_provider_free(prov);
provider_store_free(store);
CRYPTOerr(CRYPTO_F_PROVIDER_STORE_NEW, ERR_R_INTERNAL_ERROR);
return NULL;
}
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
prov->libctx = ctx;
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
prov->store = store;
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#ifndef FIPS_MODE
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
prov->error_lib = ERR_get_next_error_library();
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#endif
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
if(p->is_fallback)
ossl_provider_set_fallback(prov);
}
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
return store;
}
static const OPENSSL_CTX_METHOD provider_store_method = {
provider_store_new,
provider_store_free,
};
static struct provider_store_st *get_provider_store(OPENSSL_CTX *libctx)
{
struct provider_store_st *store = NULL;
Instead of global data store it in an OPENSSL_CTX Various core and property related code files used global data. We should store all of that in an OPENSSL_CTX instead. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8857)
2019-05-01 18:02:43 +08:00
store = openssl_ctx_get_data(libctx, OPENSSL_CTX_PROVIDER_STORE_INDEX,
&provider_store_method);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
if (store == NULL)
CRYPTOerr(CRYPTO_F_GET_PROVIDER_STORE, ERR_R_INTERNAL_ERROR);
return store;
}
Load the config file by default Previously we only loaded the config file by default for libssl. Now we do it for libcrypto too. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9492)
2019-07-30 23:42:53 +08:00
OSSL_PROVIDER *ossl_provider_find(OPENSSL_CTX *libctx, const char *name,
int noconfig)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
struct provider_store_st *store = NULL;
OSSL_PROVIDER *prov = NULL;
if ((store = get_provider_store(libctx)) != NULL) {
OSSL_PROVIDER tmpl = { 0, };
int i;
Load the config file by default Previously we only loaded the config file by default for libssl. Now we do it for libcrypto too. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9492)
2019-07-30 23:42:53 +08:00
#ifndef FIPS_MODE
/*
* Make sure any providers are loaded from config before we try to find
* them.
*/
if (!noconfig)
OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG, NULL);
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
tmpl.name = (char *)name;
CRYPTO_THREAD_write_lock(store->lock);
if ((i = sk_OSSL_PROVIDER_find(store->providers, &tmpl)) == -1
|| (prov = sk_OSSL_PROVIDER_value(store->providers, i)) == NULL
ossl_provider_upref to ossl_provider_up_ref Common pattern is that the routines to increment the reference count are called something_up_ref, not something_upref. Adapt ossl_provider_upref() accordingly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9293)
2019-07-02 20:57:36 +08:00
|| !ossl_provider_up_ref(prov))
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
prov = NULL;
CRYPTO_THREAD_unlock(store->lock);
}
return prov;
}
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
/*-
* Provider Object methods
* =======================
*/
static OSSL_PROVIDER *provider_new(const char *name,
OSSL_provider_init_fn *init_function)
{
OSSL_PROVIDER *prov = NULL;
if ((prov = OPENSSL_zalloc(sizeof(*prov))) == NULL
#ifndef HAVE_ATOMICS
|| (prov->refcnt_lock = CRYPTO_THREAD_lock_new()) == NULL
#endif
ossl_provider_upref to ossl_provider_up_ref Common pattern is that the routines to increment the reference count are called something_up_ref, not something_upref. Adapt ossl_provider_upref() accordingly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9293)
2019-07-02 20:57:36 +08:00
|| !ossl_provider_up_ref(prov) /* +1 One reference to be returned */
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
|| (prov->name = OPENSSL_strdup(name)) == NULL) {
ossl_provider_free(prov);
CRYPTOerr(CRYPTO_F_PROVIDER_NEW, ERR_R_MALLOC_FAILURE);
return NULL;
}
prov->init_function = init_function;
return prov;
}
ossl_provider_upref to ossl_provider_up_ref Common pattern is that the routines to increment the reference count are called something_up_ref, not something_upref. Adapt ossl_provider_upref() accordingly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9293)
2019-07-02 20:57:36 +08:00
int ossl_provider_up_ref(OSSL_PROVIDER *prov)
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
{
int ref = 0;
Coverity fixes covID 1445689 Resource leak (in error path) covID 1445318 Resource leak (in test - minor) covID 1443705 Unchecked return value (Needed if CRYPTO_atomic_add() was used) covID 1443691 Resource leak (in app - minor) Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9071)
2019-06-04 09:32:58 +08:00
if (CRYPTO_UP_REF(&prov->refcnt, &ref, prov->refcnt_lock) <= 0)
return 0;
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
return ref;
}
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
OSSL_PROVIDER *ossl_provider_new(OPENSSL_CTX *libctx, const char *name,
Load the config file by default Previously we only loaded the config file by default for libssl. Now we do it for libcrypto too. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9492)
2019-07-30 23:42:53 +08:00
OSSL_provider_init_fn *init_function,
int noconfig)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
struct provider_store_st *store = NULL;
OSSL_PROVIDER *prov = NULL;
if ((store = get_provider_store(libctx)) == NULL)
return NULL;
Load the config file by default Previously we only loaded the config file by default for libssl. Now we do it for libcrypto too. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9492)
2019-07-30 23:42:53 +08:00
if ((prov = ossl_provider_find(libctx, name,
noconfig)) != NULL) { /* refcount +1 */
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
ossl_provider_free(prov); /* refcount -1 */
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
ERR_raise_data(ERR_LIB_CRYPTO, CRYPTO_R_PROVIDER_ALREADY_EXISTS, NULL,
"name=%s", name);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
return NULL;
}
Replumbing: Add a mechanism to pre-populate the provider store OpenSSL will come with a set of well known providers, some of which need to be accessible from the start. These are typically built in providers, or providers that will work as fallbacks. We do this when creating a new provider store, which means that this will happen in every library context, regardless of if it's the global default one, or an explicitely created one. We keep the data about the known providers we want to make accessible this way in crypto/provider_predefined.h, which may become generated. For now, though, we make it simple and edited manually. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-18 01:06:59 +08:00
/* provider_new() generates an error, so no need here */
if ((prov = provider_new(name, init_function)) == NULL)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
return NULL;
CRYPTO_THREAD_write_lock(store->lock);
ossl_provider_upref to ossl_provider_up_ref Common pattern is that the routines to increment the reference count are called something_up_ref, not something_upref. Adapt ossl_provider_upref() accordingly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9293)
2019-07-02 20:57:36 +08:00
if (!ossl_provider_up_ref(prov)) { /* +1 One reference for the store */
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
ossl_provider_free(prov); /* -1 Reference that was to be returned */
prov = NULL;
} else if (sk_OSSL_PROVIDER_push(store->providers, prov) == 0) {
ossl_provider_free(prov); /* -1 Store reference */
ossl_provider_free(prov); /* -1 Reference that was to be returned */
prov = NULL;
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
} else {
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
prov->libctx = libctx;
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
prov->store = store;
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#ifndef FIPS_MODE
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
prov->error_lib = ERR_get_next_error_library();
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
CRYPTO_THREAD_unlock(store->lock);
if (prov == NULL)
CRYPTOerr(CRYPTO_F_OSSL_PROVIDER_NEW, ERR_R_MALLOC_FAILURE);
/*
* At this point, the provider is only partially "loaded". To be
* fully "loaded", ossl_provider_activate() must also be called.
*/
return prov;
}
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
static void free_infopair(INFOPAIR *pair)
{
OPENSSL_free(pair->name);
OPENSSL_free(pair->value);
OPENSSL_free(pair);
}
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
void ossl_provider_free(OSSL_PROVIDER *prov)
{
if (prov != NULL) {
int ref = 0;
crypto/provider_core.c: correct definition and use of lock Fixes #8476 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8477)
2019-03-14 14:59:28 +08:00
CRYPTO_DOWN_REF(&prov->refcnt, &ref, prov->refcnt_lock);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/*
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
* When the refcount drops below two, the store is the only
* possible reference, or it has already been taken away from
* the store (this may happen if a provider was activated
* because it's a fallback, but isn't currently used)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
* When that happens, the provider is inactivated.
*/
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
if (ref < 2 && prov->flag_initialized) {
Provide an ability to deregister thread stop handlers If a provider gets unloaded then any thread stop handlers that it had registered will be left hanging. We should clean them up before tearing down the provider. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9186)
2019-06-19 01:37:38 +08:00
#ifndef FIPS_MODE
ossl_init_thread_deregister(prov);
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
if (prov->teardown != NULL)
Replumbing: give the possibility for the provider to create a context OSSL_provider_init() gets another output parameter, holding a pointer to a provider side context. It's entirely up to the provider to define the context and what it's being used for. This pointer is passed back to other provider functions, typically the provider global get_params and set_params functions, and also the diverse algorithm context creators, and of course, the teardown function. With this, a provider can be instantiated more than once, or be re-loaded as the case may be, while maintaining instance state. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8848)
2019-04-30 19:41:51 +08:00
prov->teardown(prov->provctx);
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
#ifndef OPENSSL_NO_ERR
# ifndef FIPS_MODE
if (prov->error_strings != NULL) {
ERR_unload_strings(prov->error_lib, prov->error_strings);
OPENSSL_free(prov->error_strings);
prov->error_strings = NULL;
}
# endif
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
prov->flag_initialized = 0;
}
/*
* When the refcount drops to zero, it has been taken out of
* the store. All we have to do here is clean it out.
*/
if (ref == 0) {
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#ifndef FIPS_MODE
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
DSO_free(prov->module);
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
OPENSSL_free(prov->name);
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
OPENSSL_free(prov->path);
sk_INFOPAIR_pop_free(prov->parameters, free_infopair);
crypto/provider_core.c: correct definition and use of lock Fixes #8476 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8477)
2019-03-14 14:59:28 +08:00
#ifndef HAVE_ATOMICS
CRYPTO_THREAD_lock_free(prov->refcnt_lock);
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
OPENSSL_free(prov);
}
}
}
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
/* Setters */
int ossl_provider_set_module_path(OSSL_PROVIDER *prov, const char *module_path)
{
OPENSSL_free(prov->path);
if (module_path == NULL)
return 1;
if ((prov->path = OPENSSL_strdup(module_path)) != NULL)
return 1;
CRYPTOerr(CRYPTO_F_OSSL_PROVIDER_SET_MODULE_PATH, ERR_R_MALLOC_FAILURE);
return 0;
}
int ossl_provider_add_parameter(OSSL_PROVIDER *prov,
const char *name, const char *value)
{
INFOPAIR *pair = NULL;
if ((pair = OPENSSL_zalloc(sizeof(*pair))) != NULL
&& (prov->parameters != NULL
|| (prov->parameters = sk_INFOPAIR_new_null()) != NULL)
&& (pair->name = OPENSSL_strdup(name)) != NULL
&& (pair->value = OPENSSL_strdup(value)) != NULL
&& sk_INFOPAIR_push(prov->parameters, pair) > 0)
return 1;
if (pair != NULL) {
OPENSSL_free(pair->name);
OPENSSL_free(pair->value);
OPENSSL_free(pair);
}
CRYPTOerr(CRYPTO_F_OSSL_PROVIDER_ADD_PARAMETER, ERR_R_MALLOC_FAILURE);
return 0;
}
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/*
* Provider activation.
*
* What "activation" means depends on the provider form; for built in
* providers (in the library or the application alike), the provider
* can already be considered to be loaded, all that's needed is to
* initialize it. However, for dynamically loadable provider modules,
* we must first load that module.
*
* Built in modules are distinguished from dynamically loaded modules
* with an already assigned init function.
*/
static const OSSL_DISPATCH *core_dispatch; /* Define further down */
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
/*
* Internal version that doesn't affect the store flags, and thereby avoid
* locking. Direct callers must remember to set the store flags when
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
* appropriate.
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
*/
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
static int provider_activate(OSSL_PROVIDER *prov)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
const OSSL_DISPATCH *provider_dispatch = NULL;
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
#ifndef OPENSSL_NO_ERR
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# ifndef FIPS_MODE
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
OSSL_provider_get_reason_strings_fn *p_get_reason_strings = NULL;
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# endif
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
if (prov->flag_initialized)
return 1;
/*
* If the init function isn't set, it indicates that this provider is
* a loadable module.
*/
if (prov->init_function == NULL) {
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#ifdef FIPS_MODE
return 0;
#else
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
if (prov->module == NULL) {
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
char *allocated_path = NULL;
const char *module_path = NULL;
char *merged_path = NULL;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
const char *load_dir = ossl_safe_getenv("OPENSSL_MODULES");
if ((prov->module = DSO_new()) == NULL) {
/* DSO_new() generates an error already */
return 0;
}
if (load_dir == NULL)
load_dir = MODULESDIR;
DSO_ctrl(prov->module, DSO_CTRL_SET_FLAGS,
DSO_FLAG_NAME_TRANSLATION_EXT_ONLY, NULL);
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
module_path = prov->path;
if (module_path == NULL)
module_path = allocated_path =
DSO_convert_filename(prov->module, prov->name);
if (module_path != NULL)
merged_path = DSO_merge(prov->module, module_path, load_dir);
if (merged_path == NULL
|| (DSO_load(prov->module, merged_path, NULL, 0)) == NULL) {
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
DSO_free(prov->module);
prov->module = NULL;
}
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
OPENSSL_free(merged_path);
OPENSSL_free(allocated_path);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
if (prov->module != NULL)
prov->init_function = (OSSL_provider_init_fn *)
DSO_bind_func(prov->module, "OSSL_provider_init");
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
/* Call the initialise function for the provider. */
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
if (prov->init_function == NULL
Replumbing: give the possibility for the provider to create a context OSSL_provider_init() gets another output parameter, holding a pointer to a provider side context. It's entirely up to the provider to define the context and what it's being used for. This pointer is passed back to other provider functions, typically the provider global get_params and set_params functions, and also the diverse algorithm context creators, and of course, the teardown function. With this, a provider can be instantiated more than once, or be re-loaded as the case may be, while maintaining instance state. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8848)
2019-04-30 19:41:51 +08:00
|| !prov->init_function(prov, core_dispatch, &provider_dispatch,
&prov->provctx)) {
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
ERR_raise_data(ERR_LIB_CRYPTO, ERR_R_INIT_FAIL, NULL,
"name=%s", prov->name);
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#ifndef FIPS_MODE
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
DSO_free(prov->module);
prov->module = NULL;
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
return 0;
}
for (; provider_dispatch->function_id != 0; provider_dispatch++) {
switch (provider_dispatch->function_id) {
case OSSL_FUNC_PROVIDER_TEARDOWN:
prov->teardown =
OSSL_get_provider_teardown(provider_dispatch);
break;
Rename provider and core get_param_types functions It was argued that names like SOMETHING_set_param_types were confusing, and a rename has been proposed to SOMETHING_settable_params, and by consequence, SOMETHING_get_param_types is renamed SOMETHING_gettable_params. This changes implements this change for the dispatched provider and core functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9591)
2019-08-15 02:17:39 +08:00
case OSSL_FUNC_PROVIDER_GETTABLE_PARAMS:
prov->gettable_params =
OSSL_get_provider_gettable_params(provider_dispatch);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
break;
case OSSL_FUNC_PROVIDER_GET_PARAMS:
prov->get_params =
OSSL_get_provider_get_params(provider_dispatch);
break;
Replumbing: Add support for the provider query_operation function Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:57:28 +08:00
case OSSL_FUNC_PROVIDER_QUERY_OPERATION:
prov->query_operation =
OSSL_get_provider_query_operation(provider_dispatch);
break;
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
#ifndef OPENSSL_NO_ERR
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# ifndef FIPS_MODE
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
case OSSL_FUNC_PROVIDER_GET_REASON_STRINGS:
p_get_reason_strings =
OSSL_get_provider_get_reason_strings(provider_dispatch);
break;
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# endif
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
#endif
}
}
#ifndef OPENSSL_NO_ERR
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# ifndef FIPS_MODE
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
if (p_get_reason_strings != NULL) {
const OSSL_ITEM *reasonstrings = p_get_reason_strings(prov->provctx);
size_t cnt, cnt2;
/*
* ERR_load_strings() handles ERR_STRING_DATA rather than OSSL_ITEM,
* although they are essentially the same type.
* Furthermore, ERR_load_strings() patches the array's error number
* with the error library number, so we need to make a copy of that
* array either way.
*/
cnt = 1; /* One for the terminating item */
while (reasonstrings[cnt].id != 0) {
if (ERR_GET_LIB(reasonstrings[cnt].id) != 0)
return 0;
cnt++;
}
/* Allocate one extra item for the "library" name */
prov->error_strings =
OPENSSL_zalloc(sizeof(ERR_STRING_DATA) * (cnt + 1));
if (prov->error_strings == NULL)
return 0;
/*
* Set the "library" name.
*/
prov->error_strings[0].error = ERR_PACK(prov->error_lib, 0, 0);
prov->error_strings[0].string = prov->name;
/*
* Copy reasonstrings item 0..cnt-1 to prov->error_trings positions
* 1..cnt.
*/
for (cnt2 = 1; cnt2 <= cnt; cnt2++) {
prov->error_strings[cnt2].error = (int)reasonstrings[cnt2-1].id;
prov->error_strings[cnt2].string = reasonstrings[cnt2-1].ptr;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
ERR_load_strings(prov->error_lib, prov->error_strings);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
# endif
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/* With this flag set, this provider has become fully "loaded". */
prov->flag_initialized = 1;
return 1;
}
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
int ossl_provider_activate(OSSL_PROVIDER *prov)
{
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
if (provider_activate(prov)) {
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
CRYPTO_THREAD_write_lock(prov->store->lock);
prov->store->use_fallbacks = 0;
CRYPTO_THREAD_unlock(prov->store->lock);
return 1;
}
return 0;
}
Replumbing: give the possibility for the provider to create a context OSSL_provider_init() gets another output parameter, holding a pointer to a provider side context. It's entirely up to the provider to define the context and what it's being used for. This pointer is passed back to other provider functions, typically the provider global get_params and set_params functions, and also the diverse algorithm context creators, and of course, the teardown function. With this, a provider can be instantiated more than once, or be re-loaded as the case may be, while maintaining instance state. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8848)
2019-04-30 19:41:51 +08:00
void *ossl_provider_ctx(const OSSL_PROVIDER *prov)
{
return prov->provctx;
}
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
static int provider_forall_loaded(struct provider_store_st *store,
int *found_activated,
int (*cb)(OSSL_PROVIDER *provider,
void *cbdata),
void *cbdata)
{
int i;
int ret = 1;
Load the config file by default Previously we only loaded the config file by default for libssl. Now we do it for libcrypto too. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9492)
2019-07-30 23:42:53 +08:00
int num_provs;
num_provs = sk_OSSL_PROVIDER_num(store->providers);
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
if (found_activated != NULL)
*found_activated = 0;
for (i = 0; i < num_provs; i++) {
OSSL_PROVIDER *prov =
sk_OSSL_PROVIDER_value(store->providers, i);
if (prov->flag_initialized) {
if (found_activated != NULL)
*found_activated = 1;
if (!(ret = cb(prov, cbdata)))
break;
}
}
return ret;
}
Add functions to see if a provider is available for use. Public function OSSL_PROVIDER_available() takes a library context and a provider name, and returns 1 if it's available for use, i.e. if it's possible to fetch implementations from it, otherwise 0. Internal function ossl_provider_activated() returns 1 if the given OSSL_PROVIDER is activated, otherwise 0. To make this possible, the activation of fallbacks got refactored out to a separate function, which ended up simplifying the code. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9398)
2019-07-17 17:29:04 +08:00
/*
* This function only does something once when store->use_fallbacks == 1,
* and then sets store->use_fallbacks = 0, so the second call and so on is
* effectively a no-op.
*/
static void provider_activate_fallbacks(struct provider_store_st *store)
{
if (store->use_fallbacks) {
int num_provs = sk_OSSL_PROVIDER_num(store->providers);
int activated_fallback_count = 0;
int i;
for (i = 0; i < num_provs; i++) {
OSSL_PROVIDER *prov = sk_OSSL_PROVIDER_value(store->providers, i);
/*
* Note that we don't care if the activation succeeds or not.
* If it doesn't succeed, then any attempt to use any of the
* fallback providers will fail anyway.
*/
if (prov->flag_fallback) {
activated_fallback_count++;
provider_activate(prov);
}
}
/*
* We assume that all fallbacks have been added to the store before
* any fallback is activated.
* TODO: We may have to reconsider this, IF we find ourselves adding
* fallbacks after any previous fallback has been activated.
*/
if (activated_fallback_count > 0)
store->use_fallbacks = 0;
}
}
Replumbing: Add an OSSL_PROVIDER iterator with callback Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:53:34 +08:00
int ossl_provider_forall_loaded(OPENSSL_CTX *ctx,
int (*cb)(OSSL_PROVIDER *provider,
void *cbdata),
void *cbdata)
{
int ret = 1;
struct provider_store_st *store = get_provider_store(ctx);
Avoid holding a lock when calling OPENSSL_init_crypto We move an OPENSSL_init_crypto call slightly earlier in the process to avoid calling it while holding the store lock. This can lead to deadlocks. Fixes the no-engine build. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9547)
2019-08-07 17:46:26 +08:00
#ifndef FIPS_MODE
/*
* Make sure any providers are loaded from config before we try to use
* them.
*/
OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG, NULL);
#endif
Replumbing: Add an OSSL_PROVIDER iterator with callback Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:53:34 +08:00
if (store != NULL) {
CRYPTO_THREAD_read_lock(store->lock);
Add functions to see if a provider is available for use. Public function OSSL_PROVIDER_available() takes a library context and a provider name, and returns 1 if it's available for use, i.e. if it's possible to fetch implementations from it, otherwise 0. Internal function ossl_provider_activated() returns 1 if the given OSSL_PROVIDER is activated, otherwise 0. To make this possible, the activation of fallbacks got refactored out to a separate function, which ended up simplifying the code. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9398)
2019-07-17 17:29:04 +08:00
provider_activate_fallbacks(store);
Replumbing: Add an OSSL_PROVIDER iterator with callback Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:53:34 +08:00
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
/*
Add functions to see if a provider is available for use. Public function OSSL_PROVIDER_available() takes a library context and a provider name, and returns 1 if it's available for use, i.e. if it's possible to fetch implementations from it, otherwise 0. Internal function ossl_provider_activated() returns 1 if the given OSSL_PROVIDER is activated, otherwise 0. To make this possible, the activation of fallbacks got refactored out to a separate function, which ended up simplifying the code. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9398)
2019-07-17 17:29:04 +08:00
* Now, we sweep through all providers
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
*/
Add functions to see if a provider is available for use. Public function OSSL_PROVIDER_available() takes a library context and a provider name, and returns 1 if it's available for use, i.e. if it's possible to fetch implementations from it, otherwise 0. Internal function ossl_provider_activated() returns 1 if the given OSSL_PROVIDER is activated, otherwise 0. To make this possible, the activation of fallbacks got refactored out to a separate function, which ended up simplifying the code. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9398)
2019-07-17 17:29:04 +08:00
ret = provider_forall_loaded(store, NULL, cb, cbdata);
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
Replumbing: Add an OSSL_PROVIDER iterator with callback Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:53:34 +08:00
CRYPTO_THREAD_unlock(store->lock);
}
return ret;
}
Add functions to see if a provider is available for use. Public function OSSL_PROVIDER_available() takes a library context and a provider name, and returns 1 if it's available for use, i.e. if it's possible to fetch implementations from it, otherwise 0. Internal function ossl_provider_activated() returns 1 if the given OSSL_PROVIDER is activated, otherwise 0. To make this possible, the activation of fallbacks got refactored out to a separate function, which ended up simplifying the code. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9398)
2019-07-17 17:29:04 +08:00
int ossl_provider_available(OSSL_PROVIDER *prov)
{
if (prov != NULL) {
CRYPTO_THREAD_read_lock(prov->store->lock);
provider_activate_fallbacks(prov->store);
CRYPTO_THREAD_unlock(prov->store->lock);
return prov->flag_initialized;
}
return 0;
}
Replumbing: add fallback provider capability To ensure that old applications aren't left without any provider, and at the same time not forcing any default provider on applications that know how to deal with them, we device the concept of fallback providers, which are automatically activated if no other provider is already activated. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8480)
2019-03-14 17:53:27 +08:00
/* Setters of Provider Object data */
int ossl_provider_set_fallback(OSSL_PROVIDER *prov)
{
if (prov == NULL)
return 0;
prov->flag_fallback = 1;
return 1;
}
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/* Getters of Provider Object data */
Constify OSSL_PROVIDER getter input parameters Some OSSL_PROVIDER getters took a non-const OSSL_PROVIDER parameter. There's no reason to do so. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9054)
2019-05-31 16:53:12 +08:00
const char *ossl_provider_name(const OSSL_PROVIDER *prov)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
return prov->name;
}
Constify OSSL_PROVIDER getter input parameters Some OSSL_PROVIDER getters took a non-const OSSL_PROVIDER parameter. There's no reason to do so. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9054)
2019-05-31 16:53:12 +08:00
const DSO *ossl_provider_dso(const OSSL_PROVIDER *prov)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
return prov->module;
}
Constify OSSL_PROVIDER getter input parameters Some OSSL_PROVIDER getters took a non-const OSSL_PROVIDER parameter. There's no reason to do so. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9054)
2019-05-31 16:53:12 +08:00
const char *ossl_provider_module_name(const OSSL_PROVIDER *prov)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#ifdef FIPS_MODE
return NULL;
#else
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
return DSO_get_filename(prov->module);
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Constify OSSL_PROVIDER getter input parameters Some OSSL_PROVIDER getters took a non-const OSSL_PROVIDER parameter. There's no reason to do so. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9054)
2019-05-31 16:53:12 +08:00
const char *ossl_provider_module_path(const OSSL_PROVIDER *prov)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#ifdef FIPS_MODE
return NULL;
#else
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/* FIXME: Ensure it's a full path */
return DSO_get_filename(prov->module);
Make core code available within the FIPS module Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8728)
2019-04-10 22:01:40 +08:00
#endif
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
OPENSSL_CTX *ossl_provider_library_context(const OSSL_PROVIDER *prov)
{
ossl_provider_library_context(NULL) returns NULL. This will only be required until everything is moved to providers and a NULL provider pointer won't be possible. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9662)
2019-08-29 11:02:54 +08:00
/* TODO(3.0) just: return prov->libctx; */
return prov != NULL ? prov->libctx : NULL;
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
}
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/* Wrappers around calls to the provider */
void ossl_provider_teardown(const OSSL_PROVIDER *prov)
{
if (prov->teardown != NULL)
Replumbing: give the possibility for the provider to create a context OSSL_provider_init() gets another output parameter, holding a pointer to a provider side context. It's entirely up to the provider to define the context and what it's being used for. This pointer is passed back to other provider functions, typically the provider global get_params and set_params functions, and also the diverse algorithm context creators, and of course, the teardown function. With this, a provider can be instantiated more than once, or be re-loaded as the case may be, while maintaining instance state. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8848)
2019-04-30 19:41:51 +08:00
prov->teardown(prov->provctx);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Rename provider and core get_param_types functions It was argued that names like SOMETHING_set_param_types were confusing, and a rename has been proposed to SOMETHING_settable_params, and by consequence, SOMETHING_get_param_types is renamed SOMETHING_gettable_params. This changes implements this change for the dispatched provider and core functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9591)
2019-08-15 02:17:39 +08:00
const OSSL_PARAM *ossl_provider_gettable_params(const OSSL_PROVIDER *prov)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
Rename provider and core get_param_types functions It was argued that names like SOMETHING_set_param_types were confusing, and a rename has been proposed to SOMETHING_settable_params, and by consequence, SOMETHING_get_param_types is renamed SOMETHING_gettable_params. This changes implements this change for the dispatched provider and core functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9591)
2019-08-15 02:17:39 +08:00
return prov->gettable_params == NULL
? NULL : prov->gettable_params(prov->provctx);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Change OSSL_PARAM return size to not be a pointer. Instead of referencing the return size from the OSSL_PARAM structure, make the size a field within the structure. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9135)
2019-06-24 12:43:55 +08:00
int ossl_provider_get_params(const OSSL_PROVIDER *prov, OSSL_PARAM params[])
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
Replumbing: give the possibility for the provider to create a context OSSL_provider_init() gets another output parameter, holding a pointer to a provider side context. It's entirely up to the provider to define the context and what it's being used for. This pointer is passed back to other provider functions, typically the provider global get_params and set_params functions, and also the diverse algorithm context creators, and of course, the teardown function. With this, a provider can be instantiated more than once, or be re-loaded as the case may be, while maintaining instance state. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8848)
2019-04-30 19:41:51 +08:00
return prov->get_params == NULL
? 0 : prov->get_params(prov->provctx, params);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
Replumbing: Add support for the provider query_operation function Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:57:28 +08:00
const OSSL_ALGORITHM *ossl_provider_query_operation(const OSSL_PROVIDER *prov,
int operation_id,
int *no_cache)
{
Replumbing: give the possibility for the provider to create a context OSSL_provider_init() gets another output parameter, holding a pointer to a provider side context. It's entirely up to the provider to define the context and what it's being used for. This pointer is passed back to other provider functions, typically the provider global get_params and set_params functions, and also the diverse algorithm context creators, and of course, the teardown function. With this, a provider can be instantiated more than once, or be re-loaded as the case may be, while maintaining instance state. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8848)
2019-04-30 19:41:51 +08:00
return prov->query_operation(prov->provctx, operation_id, no_cache);
Replumbing: Add support for the provider query_operation function Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8340)
2019-02-25 08:57:28 +08:00
}
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
/*-
* Core functions for the provider
* ===============================
*
* This is the set of functions that the core makes available to the provider
*/
/*
* This returns a list of Provider Object parameters with their types, for
* discovery. We do not expect that many providers will use this, but one
* never knows.
*/
Replace OSSL_ITEM with OSSL_PARAM as parameter descriptor, everywhere Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9346)
2019-07-11 18:19:33 +08:00
static const OSSL_PARAM param_types[] = {
Add fips provider code for handling self test data More PR's related to self test will be derived from this PR. Note: the code removed in core_get_params() was causing a freeze since the fips module was being loaded from a config file, which then called core_get_params() which then tried to init the config fle again... Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9596)
2019-08-19 07:18:33 +08:00
OSSL_PARAM_DEFN("openssl-version", OSSL_PARAM_UTF8_PTR, NULL, 0),
Replace OSSL_ITEM with OSSL_PARAM as parameter descriptor, everywhere Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9346)
2019-07-11 18:19:33 +08:00
OSSL_PARAM_DEFN("provider-name", OSSL_PARAM_UTF8_PTR, NULL, 0),
OSSL_PARAM_END
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
};
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
/*
* Forward declare all the functions that are provided aa dispatch.
* This ensures that the compiler will complain if they aren't defined
* with the correct signature.
*/
Rename provider and core get_param_types functions It was argued that names like SOMETHING_set_param_types were confusing, and a rename has been proposed to SOMETHING_settable_params, and by consequence, SOMETHING_get_param_types is renamed SOMETHING_gettable_params. This changes implements this change for the dispatched provider and core functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9591)
2019-08-15 02:17:39 +08:00
static OSSL_core_gettable_params_fn core_gettable_params;
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
static OSSL_core_get_params_fn core_get_params;
static OSSL_core_thread_start_fn core_thread_start;
static OSSL_core_get_library_context_fn core_get_libctx;
#ifndef FIPS_MODE
static OSSL_core_new_error_fn core_new_error;
static OSSL_core_set_error_debug_fn core_set_error_debug;
static OSSL_core_vset_error_fn core_vset_error;
#endif
Rename provider and core get_param_types functions It was argued that names like SOMETHING_set_param_types were confusing, and a rename has been proposed to SOMETHING_settable_params, and by consequence, SOMETHING_get_param_types is renamed SOMETHING_gettable_params. This changes implements this change for the dispatched provider and core functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9591)
2019-08-15 02:17:39 +08:00
static const OSSL_PARAM *core_gettable_params(const OSSL_PROVIDER *prov)
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
return param_types;
}
Change OSSL_PARAM return size to not be a pointer. Instead of referencing the return size from the OSSL_PARAM structure, make the size a field within the structure. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9135)
2019-06-24 12:43:55 +08:00
static int core_get_params(const OSSL_PROVIDER *prov, OSSL_PARAM params[])
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{
int i;
Change OSSL_PARAM return size to not be a pointer. Instead of referencing the return size from the OSSL_PARAM structure, make the size a field within the structure. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9135)
2019-06-24 12:43:55 +08:00
OSSL_PARAM *p;
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
if ((p = OSSL_PARAM_locate(params, "openssl-version")) != NULL)
OSSL_PARAM_set_utf8_ptr(p, OPENSSL_VERSION_STR);
if ((p = OSSL_PARAM_locate(params, "provider-name")) != NULL)
OSSL_PARAM_set_utf8_ptr(p, prov->name);
Add fips provider code for handling self test data More PR's related to self test will be derived from this PR. Note: the code removed in core_get_params() was causing a freeze since the fips module was being loaded from a config file, which then called core_get_params() which then tried to init the config fle again... Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9596)
2019-08-19 07:18:33 +08:00
#ifndef FIPS_MODE
if ((p = OSSL_PARAM_locate(params, OSSL_PROV_PARAM_MODULE_FILENAME)) != NULL)
OSSL_PARAM_set_utf8_ptr(p, ossl_provider_module_path(prov));
#endif
Replumbing: add functionality to set provider parameters Provider parameters are parameters set by the core that the provider can retrieve. The primary use it to support making OpenSSL configuration data available to the provider. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8549)
2019-03-21 15:44:06 +08:00
if (prov->parameters == NULL)
return 1;
for (i = 0; i < sk_INFOPAIR_num(prov->parameters); i++) {
INFOPAIR *pair = sk_INFOPAIR_value(prov->parameters, i);
if ((p = OSSL_PARAM_locate(params, pair->name)) != NULL)
OSSL_PARAM_set_utf8_ptr(p, pair->value);
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
}
return 1;
}
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
static OPENSSL_CTX *core_get_libctx(const OSSL_PROVIDER *prov)
{
Prepare EVP_MAC infrastructure for moving all MACs to providers Quite a few adaptations are needed, most prominently the added code to allow provider based MACs. As part of this, all the old information functions are gone, except for EVP_MAC_name(). Some of them will reappear later, for example EVP_MAC_do_all() in some form. MACs by EVP_PKEY was particularly difficult to deal with, as they need to allocate and deallocate EVP_MAC_CTXs "under the hood", and thereby implicitly fetch the corresponding EVP_MAC. This means that EVP_MACs can't be constant in a EVP_MAC_CTX, as their reference count may need to be incremented and decremented as part of the allocation or deallocation of the EVP_MAC_CTX. It may be that other provider based EVP operation types may need to be handled in a similar manner. Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8877)
2019-05-07 18:39:58 +08:00
return ossl_provider_library_context(prov);
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
}
Tell the FIPS provider about thread stop events The RAND code needs to know about threads stopping in order to cleanup local thread data. Therefore we add a callback for libcrypto to tell providers about such events. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9040)
2019-05-27 23:31:27 +08:00
static int core_thread_start(const OSSL_PROVIDER *prov,
OSSL_thread_stop_handler_fn handfn)
{
Provide an ability to deregister thread stop handlers If a provider gets unloaded then any thread stop handlers that it had registered will be left hanging. We should clean them up before tearing down the provider. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9186)
2019-06-19 01:37:38 +08:00
return ossl_init_thread_start(prov, prov->provctx, handfn);
Tell the FIPS provider about thread stop events The RAND code needs to know about threads stopping in order to cleanup local thread data. Therefore we add a callback for libcrypto to tell providers about such events. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9040)
2019-05-27 23:31:27 +08:00
}
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
/*
* The FIPS module inner provider doesn't implement these. They aren't
* needed there, since the FIPS module upcalls are always the outer provider
* ones.
*/
#ifndef FIPS_MODE
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
/*
* TODO(3.0) These error functions should use |prov| to select the proper
* library context to report in the correct error stack, at least if error
* stacks become tied to the library context.
* We cannot currently do that since there's no support for it in the
* ERR subsystem.
*/
static void core_new_error(const OSSL_PROVIDER *prov)
{
ERR_new();
}
static void core_set_error_debug(const OSSL_PROVIDER *prov,
const char *file, int line, const char *func)
{
ERR_set_debug(file, line, func);
}
static void core_vset_error(const OSSL_PROVIDER *prov,
uint32_t reason, const char *fmt, va_list args)
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
{
/*
* If the uppermost 8 bits are non-zero, it's an OpenSSL library
* error and will be treated as such. Otherwise, it's a new style
* provider error and will be treated as such.
*/
if (ERR_GET_LIB(reason) != 0) {
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
ERR_vset_error(ERR_GET_LIB(reason), ERR_GET_REASON(reason), fmt, args);
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
} else {
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
ERR_vset_error(prov->error_lib, (int)reason, fmt, args);
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
}
}
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#endif
Replumbing: re-implement error reporting for providers The idea is that providers should only have to report a reason code. The library code is considered to be libcrypto internal, and are allocated dynamically and automatically for providers on creation. We reserve the upper 8 bits of the reason code for internal OpenSSL use. This allows our own providers to report errors in form of a packed number that includes library number, function number and reason number. With this, a provider can potentially use any reason number it wants from 1 to 16777216, although the current error semantics really only allow 1 to 4095 (because only the lower 12 bits are currently considered an actual reason code by the ERR subsystem). A provider can provide a reason string table in form of an array of ERR_STRING_DATA, with each item containing just the reason code and the associated string, with the dispatch function numbered OSSL_FUNC_PROVIDER_GET_REASON_STRINGS matching the type OSSL_provider_get_reason_strings_fn. If available, libcrypto will call that function on provider activation. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:18:31 +08:00
Make allocation/free/clean available to providers Also make OPENSSL_hexstr2buf available to providers. EVP control functions need hexstring conversion, so move any memory-allocating functions in o_str.c into new file mem_str.c Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8886)
2019-07-11 13:53:59 +08:00
/*
* Functions provided by the core. Blank line separates "families" of related
* functions.
*/
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
static const OSSL_DISPATCH core_dispatch_[] = {
Rename provider and core get_param_types functions It was argued that names like SOMETHING_set_param_types were confusing, and a rename has been proposed to SOMETHING_settable_params, and by consequence, SOMETHING_get_param_types is renamed SOMETHING_gettable_params. This changes implements this change for the dispatched provider and core functions. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/9591)
2019-08-15 02:17:39 +08:00
{ OSSL_FUNC_CORE_GETTABLE_PARAMS, (void (*)(void))core_gettable_params },
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{ OSSL_FUNC_CORE_GET_PARAMS, (void (*)(void))core_get_params },
Replumbing: offer a core upcall to get the provider object's library context The FIPS module currently has "magic" support to have the library context become the provider context within the core code, for the FIPS module's inner provider. We replace that with a core upcall that returns the library context associated with a provider object. That way, the FIPS module can handle the assignment of the inner provider context itself. This allows the FIPS module (and any other provider module that wishes to use a similar mechanism) to define for itself what the provider context is. It's currently simply a pointer to a library context, but may contain other stuff as well in the future. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:19:56 +08:00
{ OSSL_FUNC_CORE_GET_LIBRARY_CONTEXT, (void (*)(void))core_get_libctx },
Tell the FIPS provider about thread stop events The RAND code needs to know about threads stopping in order to cleanup local thread data. Therefore we add a callback for libcrypto to tell providers about such events. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9040)
2019-05-27 23:31:27 +08:00
{ OSSL_FUNC_CORE_THREAD_START, (void (*)(void))core_thread_start },
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#ifndef FIPS_MODE
Refactor provider support for reporting errors The core now supplies its own versions of ERR_new(), ERR_set_debug() and ERR_vset_error(). This should suffice for a provider to have any OpenSSL compatible functionlity it desires. The main difference between the ERR functions and the core counterparts is that the core counterparts take an OSSL_PROVIDER parameter instead of the library number. That way, providers do not need to know what number they have been assigned, that information stays in the core. Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9452)
2019-07-24 19:37:42 +08:00
{ OSSL_FUNC_CORE_NEW_ERROR, (void (*)(void))core_new_error },
{ OSSL_FUNC_CORE_SET_ERROR_DEBUG, (void (*)(void))core_set_error_debug },
{ OSSL_FUNC_CORE_VSET_ERROR, (void (*)(void))core_vset_error },
Add fips provider code for handling self test data More PR's related to self test will be derived from this PR. Note: the code removed in core_get_params() was causing a freeze since the fips module was being loaded from a config file, which then called core_get_params() which then tried to init the config fle again... Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9596)
2019-08-19 07:18:33 +08:00
{ OSSL_FUNC_BIO_NEW_FILE, (void (*)(void))BIO_new_file },
{ OSSL_FUNC_BIO_NEW_MEMBUF, (void (*)(void))BIO_new_mem_buf },
Add fips module integrity check Add environment variable for setting CONF .include path Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9769)
2019-09-15 17:55:10 +08:00
{ OSSL_FUNC_BIO_READ_EX, (void (*)(void))BIO_read_ex },
Add fips provider code for handling self test data More PR's related to self test will be derived from this PR. Note: the code removed in core_get_params() was causing a freeze since the fips module was being loaded from a config file, which then called core_get_params() which then tried to init the config fle again... Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9596)
2019-08-19 07:18:33 +08:00
{ OSSL_FUNC_BIO_FREE, (void (*)(void))BIO_free },
FIPS module: adapt for the changed error reporting methods The FIPS module inner provider doesn't need to deal with error reason strings or error library number, since it uses the outer provider's error reporting upcalls. We therefore disable that code in crypto/provider_core.c when building the FIPS module. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9174)
2019-06-18 17:39:13 +08:00
#endif
Make allocation/free/clean available to providers Also make OPENSSL_hexstr2buf available to providers. EVP control functions need hexstring conversion, so move any memory-allocating functions in o_str.c into new file mem_str.c Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Paul Dale <paul.dale@oracle.com> (Merged from https://github.com/openssl/openssl/pull/8886)
2019-07-11 13:53:59 +08:00
{ OSSL_FUNC_CRYPTO_MALLOC, (void (*)(void))CRYPTO_malloc },
{ OSSL_FUNC_CRYPTO_ZALLOC, (void (*)(void))CRYPTO_zalloc },
{ OSSL_FUNC_CRYPTO_FREE, (void (*)(void))CRYPTO_free },
{ OSSL_FUNC_CRYPTO_CLEAR_FREE, (void (*)(void))CRYPTO_clear_free },
{ OSSL_FUNC_CRYPTO_REALLOC, (void (*)(void))CRYPTO_realloc },
{ OSSL_FUNC_CRYPTO_CLEAR_REALLOC, (void (*)(void))CRYPTO_clear_realloc },
{ OSSL_FUNC_CRYPTO_SECURE_MALLOC, (void (*)(void))CRYPTO_secure_malloc },
{ OSSL_FUNC_CRYPTO_SECURE_ZALLOC, (void (*)(void))CRYPTO_secure_zalloc },
{ OSSL_FUNC_CRYPTO_SECURE_FREE, (void (*)(void))CRYPTO_secure_free },
{ OSSL_FUNC_CRYPTO_SECURE_CLEAR_FREE,
(void (*)(void))CRYPTO_secure_clear_free },
{ OSSL_FUNC_CRYPTO_SECURE_ALLOCATED,
(void (*)(void))CRYPTO_secure_allocated },
{ OSSL_FUNC_OPENSSL_CLEANSE, (void (*)(void))OPENSSL_cleanse },
Replumbing: Add the Provider Object, type OSSL_PROVIDER The OSSL_PROVIDER is the core object involved in loading a provider module, initialize a provider and do the initial communication of provider wide and core wide dispatch tables. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8287)
2019-01-20 20:14:58 +08:00
{ 0, NULL }
};
static const OSSL_DISPATCH *core_dispatch = core_dispatch_;
Reference in New Issue Copy Permalink