mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-09 05:51:54 +08:00
Code Issues Packages Projects Releases Wiki Activity
7d6766cb53
openssl/providers/common/include/prov/provider_ctx.h

41 lines
1.4 KiB
C
Raw Normal View History

Replumbing: Adapt the FIPS module to use the library context upcall Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:27:30 +08:00
/*
Update copyright year Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11839)
2020-05-15 21:09:49 +08:00
* Copyright 2019-2020 The OpenSSL Project Authors. All Rights Reserved.
Replumbing: Adapt the FIPS module to use the library context upcall Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:27:30 +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
*/
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
#ifndef OSSL_PROV_PROVIDER_CTX_H
# define OSSL_PROV_PROVIDER_CTX_H
# include <openssl/types.h>
# include <openssl/crypto.h>
# include <openssl/bio.h>
# include <openssl/core.h>
PROV: Add a proper provider context structure for OpenSSL providers The provider context structure is made to include the following information: - The core provider handle (first argument to the provider init function). This handle is meant to be used in all upcalls that need it. - A library context, used for any libcrypto calls that need it, done in the provider itself. Regarding the library context, that's generally only needed if the provider makes any libcrypto calls, i.e. is linked with libcrypto. That happens to be the case for all OpenSSL providers, but is applicable for other providers that use libcrypto internally as well. The normal thing to do for a provider init function is to create its own library context. For a provider that's meant to become a dynamically loadable module, this is what MUST be done. However, we do not do that in the default provider; it uses the library context associated with the core provider handle instead. This is permissible, although generally discouraged, as long as the provider in question is guaranteed to be built-in, into libcrypto or into the application that uses it. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11803)
2020-05-12 14:46:23 +08:00
typedef struct prov_ctx_st {
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
const OSSL_CORE_HANDLE *handle;
PROV: Add a proper provider context structure for OpenSSL providers The provider context structure is made to include the following information: - The core provider handle (first argument to the provider init function). This handle is meant to be used in all upcalls that need it. - A library context, used for any libcrypto calls that need it, done in the provider itself. Regarding the library context, that's generally only needed if the provider makes any libcrypto calls, i.e. is linked with libcrypto. That happens to be the case for all OpenSSL providers, but is applicable for other providers that use libcrypto internally as well. The normal thing to do for a provider init function is to create its own library context. For a provider that's meant to become a dynamically loadable module, this is what MUST be done. However, we do not do that in the default provider; it uses the library context associated with the core provider handle instead. This is permissible, although generally discouraged, as long as the provider in question is guaranteed to be built-in, into libcrypto or into the application that uses it. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11803)
2020-05-12 14:46:23 +08:00
OPENSSL_CTX *libctx; /* For all provider modules */
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
BIO_METHOD *corebiometh;
PROV: Add a proper provider context structure for OpenSSL providers The provider context structure is made to include the following information: - The core provider handle (first argument to the provider init function). This handle is meant to be used in all upcalls that need it. - A library context, used for any libcrypto calls that need it, done in the provider itself. Regarding the library context, that's generally only needed if the provider makes any libcrypto calls, i.e. is linked with libcrypto. That happens to be the case for all OpenSSL providers, but is applicable for other providers that use libcrypto internally as well. The normal thing to do for a provider init function is to create its own library context. For a provider that's meant to become a dynamically loadable module, this is what MUST be done. However, we do not do that in the default provider; it uses the library context associated with the core provider handle instead. This is permissible, although generally discouraged, as long as the provider in question is guaranteed to be built-in, into libcrypto or into the application that uses it. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11803)
2020-05-12 14:46:23 +08:00
} PROV_CTX;
Replumbing: Adapt the FIPS module to use the library context upcall Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9160)
2019-06-14 16:27:30 +08:00
/*
* To be used anywhere the library context needs to be passed, such as to
* fetching functions.
*/
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
# define PROV_LIBRARY_CONTEXT_OF(provctx) \
prov: prefix provider internal functions with ossl_ Also convert the names to lower case. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13014)
2020-09-28 10:47:04 +08:00
ossl_prov_ctx_get0_library_context((provctx))
PROV: Add a proper provider context structure for OpenSSL providers The provider context structure is made to include the following information: - The core provider handle (first argument to the provider init function). This handle is meant to be used in all upcalls that need it. - A library context, used for any libcrypto calls that need it, done in the provider itself. Regarding the library context, that's generally only needed if the provider makes any libcrypto calls, i.e. is linked with libcrypto. That happens to be the case for all OpenSSL providers, but is applicable for other providers that use libcrypto internally as well. The normal thing to do for a provider init function is to create its own library context. For a provider that's meant to become a dynamically loadable module, this is what MUST be done. However, we do not do that in the default provider; it uses the library context associated with the core provider handle instead. This is permissible, although generally discouraged, as long as the provider in question is guaranteed to be built-in, into libcrypto or into the application that uses it. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11803)
2020-05-12 14:46:23 +08:00
prov: prefix provider internal functions with ossl_ Also convert the names to lower case. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/13014)
2020-09-28 10:47:04 +08:00
PROV_CTX *ossl_prov_ctx_new(void);
void ossl_prov_ctx_free(PROV_CTX *ctx);
void ossl_prov_ctx_set0_library_context(PROV_CTX *ctx, OPENSSL_CTX *libctx);
void ossl_prov_ctx_set0_handle(PROV_CTX *ctx, const OSSL_CORE_HANDLE *handle);
void ossl_prov_ctx_set0_core_bio_method(PROV_CTX *ctx, BIO_METHOD *corebiometh);
OPENSSL_CTX *ossl_prov_ctx_get0_library_context(PROV_CTX *ctx);
const OSSL_CORE_HANDLE *ossl_prov_ctx_get0_handle(PROV_CTX *ctx);
BIO_METHOD *ossl_prov_ctx_get0_core_bio_method(PROV_CTX *ctx);
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
#endif
Reference in New Issue Copy Permalink