mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-27 05:21:51 +08:00
Code Issues Packages Projects Releases Wiki Activity
f32af93c92
openssl/crypto/provider_core.c

1032 lines
31 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
/*
Update copyright year Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11616)
2020-04-23 20:55:52 +08:00
* Copyright 2019-2020 The OpenSSL Project Authors. All Rights Reserved.
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
*
* 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>
cmdline app: add provider commandline options. Add a -provider option to allow providers to be loaded. This option can be specified multiple times. Add a -provider_path option to allow the path to providers to be specified. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11167)
2020-02-25 12:29:30 +08:00
#include <openssl/provider.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"
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
Add FIPS Self test kats for digests Added an API to optionally set a self test callback. The callback has the following 2 purposes (1) Output information about the KAT tests. (2) Allow the ability to corrupt one of the KAT's The fipsinstall program uses the API. Some KATS are not included in this PR since the required functionality did not yet exist in the provider. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10374)
2020-01-15 08:48:01 +08:00
# include <openssl/self_test.h>
#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
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 */
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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
/*
* 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
CORE: query for operations only once per provider (unless no_store is true) When a desired algorithm wasn't available, we didn't register anywhere that an attempt had been made, with the result that next time the same attempt was made, the whole process would be done again. To avoid this churn, we register a bit for each operation that has been queried in the libcrypto provider object, and test it before trying the same query and method construction loop again. If course, if the provider has told us not to cache, we don't register this bit. Fixes #11814 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11842)
2020-05-15 21:56:05 +08:00
/*
* Cache of bit to indicate of query_operation() has been called on
* a specific operation or not.
*/
unsigned char *operation_bits;
size_t operation_bits_sz;
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;
cmdline app: add provider commandline options. Add a -provider option to allow providers to be loaded. This option can be specified multiple times. Add a -provider_path option to allow the path to providers to be specified. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11167)
2020-02-25 12:29:30 +08:00
char *default_path;
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;
cmdline app: add provider commandline options. Add a -provider option to allow providers to be loaded. This option can be specified multiple times. Add a -provider_path option to allow the path to providers to be specified. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11167)
2020-02-25 12:29:30 +08:00
OPENSSL_free(store->default_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
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;
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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;
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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
/*
* 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;
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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) {
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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
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
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
# ifndef FIPS_MODULE
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 (prov->error_strings != NULL) {
ERR_unload_strings(prov->error_lib, prov->error_strings);
OPENSSL_free(prov->error_strings);
prov->error_strings = NULL;
}
# endif
#endif
CORE: query for operations only once per provider (unless no_store is true) When a desired algorithm wasn't available, we didn't register anywhere that an attempt had been made, with the result that next time the same attempt was made, the whole process would be done again. To avoid this churn, we register a bit for each operation that has been queried in the libcrypto provider object, and test it before trying the same query and method construction loop again. If course, if the provider has told us not to cache, we don't register this bit. Fixes #11814 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11842)
2020-05-15 21:56:05 +08:00
OPENSSL_free(prov->operation_bits);
prov->operation_bits = NULL;
prov->operation_bits_sz = 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
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) {
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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 */
cmdline app: add provider commandline options. Add a -provider option to allow providers to be loaded. This option can be specified multiple times. Add a -provider_path option to allow the path to providers to be specified. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11167)
2020-02-25 12:29:30 +08:00
int OSSL_PROVIDER_set_default_search_path(OPENSSL_CTX *libctx, const char *path)
{
struct provider_store_st *store;
char *p = NULL;
if (path != NULL) {
p = OPENSSL_strdup(path);
if (p == NULL) {
CRYPTOerr(0, ERR_R_MALLOC_FAILURE);
return 0;
}
}
if ((store = get_provider_store(libctx)) != NULL
&& CRYPTO_THREAD_write_lock(store->lock)) {
OPENSSL_free(store->default_path);
store->default_path = p;
CRYPTO_THREAD_unlock(store->lock);
return 1;
}
OPENSSL_free(p);
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
/*
* 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;
CORE: Attach the provider context to the provider late There are concerns that if |prov->provctx| is populated early, sensitive information may leak from the provider. Therefore, we use a temporary variable, and only assign it to |prov->provctx| when the provider init function has returned successfully. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11777)
2020-05-11 17:10:41 +08:00
void *tmp_provctx = NULL; /* safety measure */
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
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
# ifndef FIPS_MODULE
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) {
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifdef FIPS_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
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;
cmdline app: add provider commandline options. Add a -provider option to allow providers to be loaded. This option can be specified multiple times. Add a -provider_path option to allow the path to providers to be specified. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11167)
2020-02-25 12:29:30 +08:00
const char *load_dir = NULL;
struct provider_store_st *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
if ((prov->module = DSO_new()) == NULL) {
/* DSO_new() generates an error already */
return 0;
}
cmdline app: add provider commandline options. Add a -provider option to allow providers to be loaded. This option can be specified multiple times. Add a -provider_path option to allow the path to providers to be specified. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11167)
2020-02-25 12:29:30 +08:00
if ((store = get_provider_store(prov->libctx)) == NULL
|| !CRYPTO_THREAD_read_lock(store->lock))
return 0;
load_dir = store->default_path;
if (load_dir == NULL) {
load_dir = ossl_safe_getenv("OPENSSL_MODULES");
if (load_dir == NULL)
load_dir = MODULESDIR;
}
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_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);
cmdline app: add provider commandline options. Add a -provider option to allow providers to be loaded. This option can be specified multiple times. Add a -provider_path option to allow the path to providers to be specified. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11167)
2020-02-25 12:29:30 +08:00
CRYPTO_THREAD_unlock(store->lock);
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 (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
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
|| !prov->init_function((OSSL_CORE_HANDLE *)prov, core_dispatch,
&provider_dispatch, &tmp_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);
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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;
}
CORE: Attach the provider context to the provider late There are concerns that if |prov->provctx| is populated early, sensitive information may leak from the provider. Therefore, we use a temporary variable, and only assign it to |prov->provctx| when the provider init function has returned successfully. Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/11777)
2020-05-11 17:10:41 +08:00
prov->provctx = tmp_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
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
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
# ifndef FIPS_MODULE
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
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
# ifndef FIPS_MODULE
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.
*/
Fix off-by-1 bug on provider_activate with custom error strings Starting `cnt` from 1 would work if we weren't using cnt itself to access elements of the array returned calling the provider callback. As it is before this commit, we have 2 problems: - first, in the unlikely case that the incoming array was "empty" (only contains the terminator item) we would skip past it and potentially end up with oob reads; - otherwise, at the end of the while loop, `cnt` will be equal to the number of items in the input array, not 1 more. We then add 1 more to the zalloc call to account for the library name item, and we fill all of it (relying on zalloc to have zeroed the terminator item). The first read access that will read the list up to the terminator will result in a OOB read as we did not allocate enough space to also contain the terminator. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11427)
2020-03-27 22:39:34 +08:00
cnt = 0;
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
while (reasonstrings[cnt].id != 0) {
if (ERR_GET_LIB(reasonstrings[cnt].id) != 0)
return 0;
cnt++;
}
Fix off-by-1 bug on provider_activate with custom error strings Starting `cnt` from 1 would work if we weren't using cnt itself to access elements of the array returned calling the provider callback. As it is before this commit, we have 2 problems: - first, in the unlikely case that the incoming array was "empty" (only contains the terminator item) we would skip past it and potentially end up with oob reads; - otherwise, at the end of the while loop, `cnt` will be equal to the number of items in the input array, not 1 more. We then add 1 more to the zalloc call to account for the library name item, and we fill all of it (relying on zalloc to have zeroed the terminator item). The first read access that will read the list up to the terminator will result in a OOB read as we did not allocate enough space to also contain the terminator. Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11427)
2020-03-27 22:39:34 +08:00
cnt++; /* One for the terminating item */
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
/* 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);
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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
/*
* 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
{
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifdef FIPS_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
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
{
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifdef FIPS_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
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
}
CORE: query for operations only once per provider (unless no_store is true) When a desired algorithm wasn't available, we didn't register anywhere that an attempt had been made, with the result that next time the same attempt was made, the whole process would be done again. To avoid this churn, we register a bit for each operation that has been queried in the libcrypto provider object, and test it before trying the same query and method construction loop again. If course, if the provider has told us not to cache, we don't register this bit. Fixes #11814 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11842)
2020-05-15 21:56:05 +08:00
int ossl_provider_set_operation_bit(OSSL_PROVIDER *provider, size_t bitnum)
{
size_t byte = bitnum / 8;
unsigned char bit = (1 << (bitnum % 8)) & 0xFF;
if (provider->operation_bits_sz <= byte) {
provider->operation_bits = OPENSSL_realloc(provider->operation_bits,
byte + 1);
if (provider->operation_bits == NULL) {
ERR_raise(ERR_LIB_CRYPTO, ERR_R_MALLOC_FAILURE);
return 0;
}
memset(provider->operation_bits + provider->operation_bits_sz,
'\0', byte + 1 - provider->operation_bits_sz);
}
provider->operation_bits[byte] |= bit;
return 1;
}
int ossl_provider_test_operation_bit(OSSL_PROVIDER *provider, size_t bitnum,
int *result)
{
size_t byte = bitnum / 8;
unsigned char bit = (1 << (bitnum % 8)) & 0xFF;
if (!ossl_assert(result != NULL)) {
ERR_raise(ERR_LIB_CRYPTO, ERR_R_PASSED_NULL_PARAMETER);
return 0;
}
*result = 0;
if (provider->operation_bits_sz > byte)
*result = ((provider->operation_bits[byte] & bit) != 0);
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
/*-
* 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;
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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_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;
PROV: Add support for error queue marks and implement in FIPS module This propagates ERR_set_mark(), and ERR_clear_last_mark() and ERR_pop_to_mark() for provider use. Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10803)
2020-01-15 21:09:54 +08:00
static OSSL_core_set_error_mark_fn core_set_error_mark;
static OSSL_core_clear_last_error_mark_fn core_clear_last_error_mark;
static OSSL_core_pop_error_to_mark_fn core_pop_error_to_mark;
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
#endif
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static const OSSL_PARAM *core_gettable_params(const OSSL_CORE_HANDLE *handle)
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;
}
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static int core_get_params(const OSSL_CORE_HANDLE *handle, 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;
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
/*
* We created this object originally and we know it is actually an
* OSSL_PROVIDER *, so the cast is safe
*/
OSSL_PROVIDER *prov = (OSSL_PROVIDER *)handle;
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);
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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
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;
}
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static OPENSSL_CORE_CTX *core_get_libctx(const OSSL_CORE_HANDLE *handle)
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
{
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
/*
* We created this object originally and we know it is actually an
* OSSL_PROVIDER *, so the cast is safe
*/
OSSL_PROVIDER *prov = (OSSL_PROVIDER *)handle;
return (OPENSSL_CORE_CTX *)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
}
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static int core_thread_start(const OSSL_CORE_HANDLE *handle,
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_thread_stop_handler_fn handfn)
{
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
/*
* We created this object originally and we know it is actually an
* OSSL_PROVIDER *, so the cast is safe
*/
OSSL_PROVIDER *prov = (OSSL_PROVIDER *)handle;
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.
*/
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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
/*
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
* TODO(3.0) These error functions should use |handle| to select the proper
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
* 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.
*/
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static void core_new_error(const OSSL_CORE_HANDLE *handle)
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_new();
}
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static void core_set_error_debug(const OSSL_CORE_HANDLE *handle,
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
const char *file, int line, const char *func)
{
ERR_set_debug(file, line, func);
}
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static void core_vset_error(const OSSL_CORE_HANDLE *handle,
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
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
{
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
/*
* We created this object originally and we know it is actually an
* OSSL_PROVIDER *, so the cast is safe
*/
OSSL_PROVIDER *prov = (OSSL_PROVIDER *)handle;
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
}
}
PROV: Add support for error queue marks and implement in FIPS module This propagates ERR_set_mark(), and ERR_clear_last_mark() and ERR_pop_to_mark() for provider use. Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10803)
2020-01-15 21:09:54 +08:00
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static int core_set_error_mark(const OSSL_CORE_HANDLE *handle)
PROV: Add support for error queue marks and implement in FIPS module This propagates ERR_set_mark(), and ERR_clear_last_mark() and ERR_pop_to_mark() for provider use. Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10803)
2020-01-15 21:09:54 +08:00
{
return ERR_set_mark();
}
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static int core_clear_last_error_mark(const OSSL_CORE_HANDLE *handle)
PROV: Add support for error queue marks and implement in FIPS module This propagates ERR_set_mark(), and ERR_clear_last_mark() and ERR_pop_to_mark() for provider use. Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10803)
2020-01-15 21:09:54 +08:00
{
return ERR_clear_last_mark();
}
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
static int core_pop_error_to_mark(const OSSL_CORE_HANDLE *handle)
PROV: Add support for error queue marks and implement in FIPS module This propagates ERR_set_mark(), and ERR_clear_last_mark() and ERR_pop_to_mark() for provider use. Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10803)
2020-01-15 21:09:54 +08:00
{
return ERR_pop_to_mark();
}
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#endif /* FIPS_MODULE */
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 },
Rename FIPS_MODE to FIPS_MODULE This macro is used to determine if certain pieces of code should become part of the FIPS module or not. The old name was confusing. Fixes #11538 Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from https://github.com/openssl/openssl/pull/11539)
2020-04-14 04:34:56 +08:00
#ifndef FIPS_MODULE
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 },
PROV: Add support for error queue marks and implement in FIPS module This propagates ERR_set_mark(), and ERR_clear_last_mark() and ERR_pop_to_mark() for provider use. Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> (Merged from https://github.com/openssl/openssl/pull/10803)
2020-01-15 21:09:54 +08:00
{ OSSL_FUNC_CORE_SET_ERROR_MARK, (void (*)(void))core_set_error_mark },
{ OSSL_FUNC_CORE_CLEAR_LAST_ERROR_MARK,
(void (*)(void))core_clear_last_error_mark },
Add RSA sign to the fips provider Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11199)
2020-03-15 15:38:00 +08:00
{ OSSL_FUNC_CORE_POP_ERROR_TO_MARK, (void (*)(void))core_pop_error_to_mark },
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 },
Maintain strict type discipline between the core and providers A provider could be linked against a different version of libcrypto than the version of libcrypto that loaded the provider. Different versions of libcrypto could define opaque types differently. It must never occur that a type created in one libcrypto is used directly by the other libcrypto. This will cause crashes. We can "cheat" for "built-in" providers that are part of libcrypto itself, because we know that the two libcrypto versions are the same - but not for other providers. To ensure this does not occur we use different types names for the handful of opaque types that are passed between the core and providers. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11758)
2020-05-06 19:29:57 +08:00
{ OSSL_FUNC_BIO_WRITE_EX, (void (*)(void))BIO_write_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 },
PROV BIO: add a BIO_vprintf() upcall, and a provider BIO library The BIO_vprintf() will allow the provider to print any text, given a BIO supplied by libcrypto. Additionally, we add a provider library with functions to collect all the currently supplied BIO upcalls, as well as wrappers around those upcalls. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10394)
2019-11-18 08:50:18 +08:00
{ OSSL_FUNC_BIO_VPRINTF, (void (*)(void))BIO_vprintf },
Add RSA sign to the fips provider Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11199)
2020-03-15 15:38:00 +08:00
{ OSSL_FUNC_BIO_VSNPRINTF, (void (*)(void))BIO_vsnprintf },
Add FIPS Self test kats for digests Added an API to optionally set a self test callback. The callback has the following 2 purposes (1) Output information about the KAT tests. (2) Allow the ability to corrupt one of the KAT's The fipsinstall program uses the API. Some KATS are not included in this PR since the required functionality did not yet exist in the provider. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10374)
2020-01-15 08:48:01 +08:00
{ OSSL_FUNC_SELF_TEST_CB, (void (*)(void))OSSL_SELF_TEST_get_callback },
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