2019-02-09 00:01:56 +08:00
|
|
|
/*
|
|
|
|
* Copyright 2019 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License 2.0 (the "License"). You may not use
|
|
|
|
* this file except in compliance with the License. You can obtain a copy
|
|
|
|
* in the file LICENSE in the source distribution or at
|
|
|
|
* https://www.openssl.org/source/license.html
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stddef.h>
|
2019-09-28 06:45:46 +08:00
|
|
|
#include <openssl/types.h>
|
2019-02-09 00:01:56 +08:00
|
|
|
#include <openssl/evp.h>
|
|
|
|
#include <openssl/core.h>
|
|
|
|
#include "internal/cryptlib.h"
|
|
|
|
#include "internal/thread_once.h"
|
|
|
|
#include "internal/property.h"
|
|
|
|
#include "internal/core.h"
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
#include "internal/provider.h"
|
2019-05-04 18:56:32 +08:00
|
|
|
#include "internal/namemap.h"
|
2019-09-28 06:45:40 +08:00
|
|
|
#include "crypto/evp.h" /* evp_local.h needs it */
|
|
|
|
#include "evp_local.h"
|
2019-02-09 00:01:56 +08:00
|
|
|
|
2019-05-23 09:36:21 +08:00
|
|
|
#define NAME_SEPARATOR ':'
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void evp_method_store_free(void *vstore)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
ossl_method_store_free(vstore);
|
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void *evp_method_store_new(OPENSSL_CTX *ctx)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-05-01 18:02:43 +08:00
|
|
|
return ossl_method_store_new(ctx);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static const OPENSSL_CTX_METHOD evp_method_store_method = {
|
|
|
|
evp_method_store_new,
|
|
|
|
evp_method_store_free,
|
2019-02-09 00:01:56 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Data to be passed through ossl_method_construct() */
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st {
|
2019-05-04 18:56:32 +08:00
|
|
|
OPENSSL_CTX *libctx;
|
2019-02-09 00:01:56 +08:00
|
|
|
OSSL_METHOD_CONSTRUCT_METHOD *mcm;
|
2019-10-24 23:04:01 +08:00
|
|
|
int operation_id; /* For get_evp_method_from_store() */
|
|
|
|
int name_id; /* For get_evp_method_from_store() */
|
|
|
|
const char *names; /* For get_evp_method_from_store() */
|
|
|
|
const char *propquery; /* For get_evp_method_from_store() */
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
void *(*method_from_dispatch)(int name_id, const OSSL_DISPATCH *,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *);
|
2019-02-09 00:01:56 +08:00
|
|
|
int (*refcnt_up_method)(void *method);
|
|
|
|
void (*destruct_method)(void *method);
|
|
|
|
};
|
|
|
|
|
2019-05-23 09:36:21 +08:00
|
|
|
static int add_names_to_namemap(OSSL_NAMEMAP *namemap,
|
|
|
|
const char *names)
|
|
|
|
{
|
|
|
|
const char *p, *q;
|
|
|
|
size_t l;
|
|
|
|
int id = 0;
|
|
|
|
|
|
|
|
/* Check that we have a namemap and that there is at least one name */
|
|
|
|
if (namemap == NULL) {
|
|
|
|
ERR_raise(ERR_LIB_EVP, ERR_R_PASSED_NULL_PARAMETER);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check that no name is an empty string, and that all names have at
|
|
|
|
* most one numeric identity together.
|
|
|
|
*/
|
|
|
|
for (p = names; *p != '\0'; p = (q == NULL ? p + l : q + 1)) {
|
|
|
|
int this_id;
|
|
|
|
|
|
|
|
if ((q = strchr(p, NAME_SEPARATOR)) == NULL)
|
|
|
|
l = strlen(p); /* offset to \0 */
|
|
|
|
else
|
|
|
|
l = q - p; /* offset to the next separator */
|
|
|
|
|
|
|
|
this_id = ossl_namemap_name2num_n(namemap, p, l);
|
|
|
|
|
|
|
|
if (*p == '\0' || *p == NAME_SEPARATOR) {
|
|
|
|
ERR_raise(ERR_LIB_EVP, EVP_R_BAD_ALGORITHM_NAME);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
if (id == 0)
|
|
|
|
id = this_id;
|
|
|
|
else if (this_id != 0 && this_id != id) {
|
|
|
|
ERR_raise_data(ERR_LIB_EVP, EVP_R_CONFLICTING_ALGORITHM_NAME,
|
|
|
|
"\"%.*s\" has an existing different identity %d (from \"%s\")",
|
|
|
|
l, p, this_id, names);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Now that we have checked, register all names */
|
|
|
|
for (p = names; *p != '\0'; p = (q == NULL ? p + l : q + 1)) {
|
|
|
|
int this_id;
|
|
|
|
|
|
|
|
if ((q = strchr(p, NAME_SEPARATOR)) == NULL)
|
|
|
|
l = strlen(p); /* offset to \0 */
|
|
|
|
else
|
|
|
|
l = q - p; /* offset to the next separator */
|
|
|
|
|
|
|
|
this_id = ossl_namemap_add_n(namemap, id, p, l);
|
|
|
|
if (id == 0)
|
|
|
|
id = this_id;
|
|
|
|
else if (this_id != id) {
|
|
|
|
ERR_raise_data(ERR_LIB_EVP, ERR_R_INTERNAL_ERROR,
|
|
|
|
"Got id %d when expecting %d", this_id, id);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return id;
|
|
|
|
}
|
|
|
|
|
2019-05-23 09:27:37 +08:00
|
|
|
#ifndef FIPS_MODE
|
|
|
|
/* Creates an initial namemap with names found in the legacy method db */
|
|
|
|
static void get_legacy_evp_names(const char *main_name, const char *alias,
|
|
|
|
void *arg)
|
|
|
|
{
|
|
|
|
int main_id = ossl_namemap_add(arg, 0, main_name);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We could check that the returned value is the same as main_id,
|
|
|
|
* but since this is a void function, there's no sane way to report
|
|
|
|
* the error. The best we can do is trust ourselve to keep the legacy
|
|
|
|
* method database conflict free.
|
|
|
|
*
|
|
|
|
* This registers any alias with the same number as the main name.
|
|
|
|
* Should it be that the current |on| *has* the main name, this is
|
|
|
|
* simply a no-op.
|
|
|
|
*/
|
|
|
|
if (alias != NULL)
|
|
|
|
(void)ossl_namemap_add(arg, main_id, alias);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void get_legacy_cipher_names(const OBJ_NAME *on, void *arg)
|
|
|
|
{
|
|
|
|
const EVP_CIPHER *cipher = (void *)OBJ_NAME_get(on->name, on->type);
|
|
|
|
|
|
|
|
get_legacy_evp_names(EVP_CIPHER_name(cipher), on->name, arg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void get_legacy_md_names(const OBJ_NAME *on, void *arg)
|
|
|
|
{
|
|
|
|
const EVP_MD *md = (void *)OBJ_NAME_get(on->name, on->type);
|
|
|
|
/* We don't want the pkey_type names, so we need some extra care */
|
|
|
|
int snid, lnid;
|
|
|
|
|
|
|
|
snid = OBJ_sn2nid(on->name);
|
|
|
|
lnid = OBJ_ln2nid(on->name);
|
|
|
|
if (snid != EVP_MD_pkey_type(md) && lnid != EVP_MD_pkey_type(md))
|
|
|
|
get_legacy_evp_names(EVP_MD_name(md), on->name, arg);
|
|
|
|
else
|
|
|
|
get_legacy_evp_names(EVP_MD_name(md), NULL, arg);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static OSSL_NAMEMAP *get_prepopulated_namemap(OPENSSL_CTX *libctx)
|
|
|
|
{
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
#ifndef FIPS_MODE
|
|
|
|
if (namemap != NULL && ossl_namemap_empty(namemap)) {
|
|
|
|
/* Before pilfering, we make sure the legacy database is populated */
|
|
|
|
OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_CIPHERS
|
|
|
|
|OPENSSL_INIT_ADD_ALL_DIGESTS, NULL);
|
|
|
|
|
|
|
|
OBJ_NAME_do_all(OBJ_NAME_TYPE_CIPHER_METH,
|
|
|
|
get_legacy_cipher_names, namemap);
|
|
|
|
OBJ_NAME_do_all(OBJ_NAME_TYPE_MD_METH,
|
|
|
|
get_legacy_md_names, namemap);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return namemap;
|
|
|
|
}
|
|
|
|
|
2019-02-09 00:01:56 +08:00
|
|
|
/*
|
|
|
|
* Generic routines to fetch / create EVP methods with ossl_method_construct()
|
|
|
|
*/
|
2019-10-24 23:04:01 +08:00
|
|
|
static void *alloc_tmp_evp_method_store(OPENSSL_CTX *ctx)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-05-01 18:02:43 +08:00
|
|
|
return ossl_method_store_new(ctx);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void dealloc_tmp_evp_method_store(void *store)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
|
|
|
if (store != NULL)
|
|
|
|
ossl_method_store_free(store);
|
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static OSSL_METHOD_STORE *get_evp_method_store(OPENSSL_CTX *libctx)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
return openssl_ctx_get_data(libctx, OPENSSL_CTX_EVP_METHOD_STORE_INDEX,
|
|
|
|
&evp_method_store_method);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* To identity the method in the EVP method store, we mix the name identity
|
|
|
|
* with the operation identity, with the assumption that we don't have more
|
|
|
|
* than 2^24 names or more than 2^8 operation types.
|
2019-06-07 17:44:08 +08:00
|
|
|
*
|
|
|
|
* The resulting identity is a 32-bit integer, composed like this:
|
|
|
|
*
|
|
|
|
* +---------24 bits--------+-8 bits-+
|
|
|
|
* | name identity | op id |
|
|
|
|
* +------------------------+--------+
|
|
|
|
*/
|
2019-10-24 23:04:01 +08:00
|
|
|
static uint32_t evp_method_id(unsigned int operation_id, int name_id)
|
2019-06-07 17:44:08 +08:00
|
|
|
{
|
|
|
|
if (!ossl_assert(name_id < (1 << 24) || operation_id < (1 << 8))
|
|
|
|
|| !ossl_assert(name_id > 0 && operation_id > 0))
|
|
|
|
return 0;
|
|
|
|
return ((name_id << 8) & 0xFFFFFF00) | (operation_id & 0x000000FF);
|
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void *get_evp_method_from_store(OPENSSL_CTX *libctx, void *store,
|
|
|
|
void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
2019-02-09 00:01:56 +08:00
|
|
|
void *method = NULL;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
int name_id;
|
|
|
|
uint32_t meth_id;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* get_evp_method_from_store() is only called to try and get the method
|
|
|
|
* that evp_generic_fetch() is asking for, and the operation id as well
|
|
|
|
* as the name or name id are passed via methdata.
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
*/
|
|
|
|
if ((name_id = methdata->name_id) == 0) {
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
2019-05-23 09:36:21 +08:00
|
|
|
const char *names = methdata->names;
|
|
|
|
const char *q = strchr(names, NAME_SEPARATOR);
|
|
|
|
size_t l = (q == NULL ? strlen(names) : (size_t)(q - names));
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
|
|
|
|
if (namemap == 0)
|
|
|
|
return NULL;
|
2019-05-23 09:36:21 +08:00
|
|
|
name_id = ossl_namemap_name2num_n(namemap, names, l);
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (name_id == 0
|
2019-10-24 23:04:01 +08:00
|
|
|
|| (meth_id = evp_method_id(methdata->operation_id, name_id)) == 0)
|
2019-02-09 00:01:56 +08:00
|
|
|
return NULL;
|
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
if (store == NULL
|
2019-10-24 23:04:01 +08:00
|
|
|
&& (store = get_evp_method_store(libctx)) == NULL)
|
2019-05-05 14:42:21 +08:00
|
|
|
return NULL;
|
|
|
|
|
2019-11-11 09:17:32 +08:00
|
|
|
if (!ossl_method_store_fetch(store, meth_id, methdata->propquery,
|
|
|
|
&method))
|
|
|
|
return NULL;
|
2019-02-09 00:01:56 +08:00
|
|
|
return method;
|
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static int put_evp_method_in_store(OPENSSL_CTX *libctx, void *store,
|
|
|
|
void *method, const OSSL_PROVIDER *prov,
|
|
|
|
int operation_id, const char *names,
|
|
|
|
const char *propdef, void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
2019-05-05 14:42:21 +08:00
|
|
|
OSSL_NAMEMAP *namemap;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
int name_id;
|
|
|
|
uint32_t meth_id;
|
2019-05-23 09:36:21 +08:00
|
|
|
size_t l = 0;
|
2019-03-21 01:51:29 +08:00
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* put_evp_method_in_store() is only called with an EVP method that was
|
|
|
|
* successfully created by construct_method() below, which means that
|
|
|
|
* all the names should already be stored in the namemap with the same
|
|
|
|
* numeric identity, so just use the first to get that identity.
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
*/
|
2019-05-23 09:36:21 +08:00
|
|
|
if (names != NULL) {
|
|
|
|
const char *q = strchr(names, NAME_SEPARATOR);
|
|
|
|
|
|
|
|
l = (q == NULL ? strlen(names) : (size_t)(q - names));
|
|
|
|
}
|
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
if ((namemap = ossl_namemap_stored(libctx)) == NULL
|
2019-05-23 09:36:21 +08:00
|
|
|
|| (name_id = ossl_namemap_name2num_n(namemap, names, l)) == 0
|
2019-10-24 23:04:01 +08:00
|
|
|
|| (meth_id = evp_method_id(operation_id, name_id)) == 0)
|
2019-03-21 01:51:29 +08:00
|
|
|
return 0;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
if (store == NULL
|
2019-10-24 23:04:01 +08:00
|
|
|
&& (store = get_evp_method_store(libctx)) == NULL)
|
2019-02-09 00:01:56 +08:00
|
|
|
return 0;
|
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
return ossl_method_store_add(store, prov, meth_id, propdef, method,
|
2019-08-21 15:58:10 +08:00
|
|
|
methdata->refcnt_up_method,
|
|
|
|
methdata->destruct_method);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
|
|
|
* The core fetching functionality passes the name of the implementation.
|
|
|
|
* This function is responsible to getting an identity number for it.
|
|
|
|
*/
|
2019-10-24 23:04:01 +08:00
|
|
|
static void *construct_evp_method(const char *names, const OSSL_DISPATCH *fns,
|
|
|
|
OSSL_PROVIDER *prov, void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* This function is only called if get_evp_method_from_store() returned
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
* NULL, so it's safe to say that of all the spots to create a new
|
|
|
|
* namemap entry, this is it. Should the name already exist there, we
|
|
|
|
* know that ossl_namemap_add() will return its corresponding number.
|
|
|
|
*/
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
2019-05-23 09:36:21 +08:00
|
|
|
int name_id = add_names_to_namemap(namemap, names);
|
2019-02-09 00:01:56 +08:00
|
|
|
|
2019-05-23 09:36:21 +08:00
|
|
|
if (name_id == 0)
|
|
|
|
return NULL;
|
2019-10-31 19:10:01 +08:00
|
|
|
return methdata->method_from_dispatch(name_id, fns, prov);
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void destruct_evp_method(void *method, void *data)
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st *methdata = data;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
methdata->destruct_method(method);
|
|
|
|
}
|
|
|
|
|
2019-10-24 23:04:01 +08:00
|
|
|
static void *
|
|
|
|
inner_evp_generic_fetch(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
int name_id, const char *name,
|
|
|
|
const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
2019-10-24 23:04:01 +08:00
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
2019-02-09 00:01:56 +08:00
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
OSSL_METHOD_STORE *store = get_evp_method_store(libctx);
|
2019-05-23 09:27:37 +08:00
|
|
|
OSSL_NAMEMAP *namemap = get_prepopulated_namemap(libctx);
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
uint32_t meth_id = 0;
|
2019-02-09 00:01:56 +08:00
|
|
|
void *method = NULL;
|
|
|
|
|
2019-05-04 18:56:32 +08:00
|
|
|
if (store == NULL || namemap == NULL)
|
2019-04-18 18:23:21 +08:00
|
|
|
return NULL;
|
|
|
|
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
|
|
|
* If there's ever an operation_id == 0 passed, we have an internal
|
|
|
|
* programming error.
|
|
|
|
*/
|
|
|
|
if (!ossl_assert(operation_id > 0))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
* If we have been passed neither a name_id or a name, we have an
|
|
|
|
* internal programming error.
|
|
|
|
*/
|
|
|
|
if (!ossl_assert(name_id != 0 || name != NULL))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* If we haven't received a name id yet, try to get one for the name */
|
|
|
|
if (name_id == 0)
|
|
|
|
name_id = ossl_namemap_name2num(namemap, name);
|
|
|
|
|
|
|
|
/*
|
2019-10-24 23:04:01 +08:00
|
|
|
* If we have a name id, calculate a method id with evp_method_id().
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
*
|
2019-10-24 23:04:01 +08:00
|
|
|
* evp_method_id returns 0 if we have too many operations (more than
|
|
|
|
* about 2^8) or too many names (more than about 2^24). In that case,
|
|
|
|
* we can't create any new method.
|
2019-06-07 17:44:08 +08:00
|
|
|
*/
|
2019-10-24 23:04:01 +08:00
|
|
|
if (name_id != 0 && (meth_id = evp_method_id(operation_id, name_id)) == 0)
|
2019-06-07 17:44:08 +08:00
|
|
|
return NULL;
|
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
if (meth_id == 0
|
|
|
|
|| !ossl_method_store_cache_get(store, meth_id, properties, &method)) {
|
2019-02-09 00:01:56 +08:00
|
|
|
OSSL_METHOD_CONSTRUCT_METHOD mcm = {
|
2019-10-24 23:04:01 +08:00
|
|
|
alloc_tmp_evp_method_store,
|
|
|
|
dealloc_tmp_evp_method_store,
|
|
|
|
get_evp_method_from_store,
|
|
|
|
put_evp_method_in_store,
|
|
|
|
construct_evp_method,
|
|
|
|
destruct_evp_method
|
2019-02-09 00:01:56 +08:00
|
|
|
};
|
2019-10-24 23:04:01 +08:00
|
|
|
struct evp_method_data_st mcmdata;
|
2019-02-09 00:01:56 +08:00
|
|
|
|
|
|
|
mcmdata.mcm = &mcm;
|
2019-05-04 18:56:32 +08:00
|
|
|
mcmdata.libctx = libctx;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
mcmdata.operation_id = operation_id;
|
|
|
|
mcmdata.name_id = name_id;
|
2019-05-23 09:36:21 +08:00
|
|
|
mcmdata.names = name;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
mcmdata.propquery = properties;
|
2019-02-09 00:01:56 +08:00
|
|
|
mcmdata.method_from_dispatch = new_method;
|
2019-07-02 20:57:36 +08:00
|
|
|
mcmdata.refcnt_up_method = up_ref_method;
|
2019-02-09 00:01:56 +08:00
|
|
|
mcmdata.destruct_method = free_method;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
if ((method = ossl_method_construct(libctx, operation_id,
|
|
|
|
0 /* !force_cache */,
|
2019-06-28 21:29:34 +08:00
|
|
|
&mcm, &mcmdata)) != NULL) {
|
2019-06-07 17:44:08 +08:00
|
|
|
/*
|
|
|
|
* If construction did create a method for us, we know that
|
2019-10-24 23:04:01 +08:00
|
|
|
* there is a correct name_id and meth_id, since those have
|
|
|
|
* already been calculated in get_evp_method_from_store() and
|
|
|
|
* put_evp_method_in_store() above.
|
2019-06-07 17:44:08 +08:00
|
|
|
*/
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
if (name_id == 0)
|
|
|
|
name_id = ossl_namemap_name2num(namemap, name);
|
2019-10-24 23:04:01 +08:00
|
|
|
meth_id = evp_method_id(operation_id, name_id);
|
2019-11-11 09:17:32 +08:00
|
|
|
ossl_method_store_cache_set(store, meth_id, properties, method,
|
|
|
|
up_ref_method, free_method);
|
2019-06-07 17:44:08 +08:00
|
|
|
}
|
2019-02-09 00:01:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return method;
|
|
|
|
}
|
2019-04-05 16:46:18 +08:00
|
|
|
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
void *evp_generic_fetch(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
const char *name, const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
return inner_evp_generic_fetch(libctx,
|
|
|
|
operation_id, 0, name, properties,
|
2019-10-31 19:10:01 +08:00
|
|
|
new_method, up_ref_method, free_method);
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* evp_generic_fetch_by_number() is special, and only returns methods for
|
|
|
|
* already known names, i.e. it refuses to work if no name_id can be found
|
|
|
|
* (it's considered an internal programming error).
|
|
|
|
* This is meant to be used when one method needs to fetch an associated
|
|
|
|
* other method.
|
|
|
|
*/
|
|
|
|
void *evp_generic_fetch_by_number(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
int name_id, const char *properties,
|
|
|
|
void *(*new_method)(int name_id,
|
|
|
|
const OSSL_DISPATCH *fns,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
int (*up_ref_method)(void *),
|
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
return inner_evp_generic_fetch(libctx,
|
|
|
|
operation_id, name_id, NULL, properties,
|
2019-10-31 19:10:01 +08:00
|
|
|
new_method, up_ref_method, free_method);
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
}
|
|
|
|
|
2019-04-05 16:46:18 +08:00
|
|
|
int EVP_set_default_properties(OPENSSL_CTX *libctx, const char *propq)
|
|
|
|
{
|
2019-10-24 23:04:01 +08:00
|
|
|
OSSL_METHOD_STORE *store = get_evp_method_store(libctx);
|
2019-04-05 16:46:18 +08:00
|
|
|
|
|
|
|
if (store != NULL)
|
|
|
|
return ossl_method_store_set_global_properties(store, propq);
|
|
|
|
EVPerr(EVP_F_EVP_SET_DEFAULT_PROPERTIES, ERR_R_INTERNAL_ERROR);
|
|
|
|
return 0;
|
|
|
|
}
|
2019-07-13 12:53:44 +08:00
|
|
|
|
|
|
|
struct do_all_data_st {
|
|
|
|
void (*user_fn)(void *method, void *arg);
|
|
|
|
void *user_arg;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
void *(*new_method)(const int name_id, const OSSL_DISPATCH *fns,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov);
|
2019-07-13 12:53:44 +08:00
|
|
|
void (*free_method)(void *);
|
|
|
|
};
|
|
|
|
|
|
|
|
static void do_one(OSSL_PROVIDER *provider, const OSSL_ALGORITHM *algo,
|
|
|
|
int no_store, void *vdata)
|
|
|
|
{
|
|
|
|
struct do_all_data_st *data = vdata;
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(provider);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
2019-05-23 09:36:21 +08:00
|
|
|
int name_id = add_names_to_namemap(namemap, algo->algorithm_names);
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
void *method = NULL;
|
|
|
|
|
|
|
|
if (name_id != 0)
|
2019-10-31 19:10:01 +08:00
|
|
|
method = data->new_method(name_id, algo->implementation, provider);
|
2019-07-13 12:53:44 +08:00
|
|
|
|
|
|
|
if (method != NULL) {
|
|
|
|
data->user_fn(method, data->user_arg);
|
|
|
|
data->free_method(method);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void evp_generic_do_all(OPENSSL_CTX *libctx, int operation_id,
|
|
|
|
void (*user_fn)(void *method, void *arg),
|
|
|
|
void *user_arg,
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
void *(*new_method)(int name_id,
|
2019-07-13 12:53:44 +08:00
|
|
|
const OSSL_DISPATCH *fns,
|
2019-10-31 19:10:01 +08:00
|
|
|
OSSL_PROVIDER *prov),
|
2019-07-13 12:53:44 +08:00
|
|
|
void (*free_method)(void *))
|
|
|
|
{
|
|
|
|
struct do_all_data_st data;
|
|
|
|
|
|
|
|
data.new_method = new_method;
|
|
|
|
data.free_method = free_method;
|
|
|
|
data.user_fn = user_fn;
|
|
|
|
data.user_arg = user_arg;
|
2019-09-24 09:42:18 +08:00
|
|
|
ossl_algorithm_do_all(libctx, operation_id, NULL, do_one, &data);
|
2019-07-13 12:53:44 +08:00
|
|
|
}
|
In provider implemented methods, save the name number, not the name string
Multiple names per implementation is already supported in the namemap,
but hasn't been used yet. However, as soon as we have multiple names,
we will get an issue with what name should be saved in the method.
The solution is to not save the name itself, but rather the number
it's associated with. This number is supposed to be unique for each
set of names, and we assume that algorithm names are globally unique,
i.e. there can be no name overlap between different algorithm types.
Incidently, it was also found that the 'get' function used by
ossl_construct_method() doesn't need all the parameters it was given;
most of what it needs, it can now get through the data structure given
by the caller of ossl_construct_method(). As a consequence,
ossl_construct_method() itself doesn't need all the parameters it was
given either.
There are some added internal functions that are expected to disappear
as soon as legacy code is removed, such as evp_first_name() and
ossl_namemap_num2name().
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9897)
2019-09-14 22:22:19 +08:00
|
|
|
|
|
|
|
const char *evp_first_name(OSSL_PROVIDER *prov, int name_id)
|
|
|
|
{
|
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
return ossl_namemap_num2name(namemap, name_id, 0);
|
|
|
|
}
|
2019-09-14 22:35:08 +08:00
|
|
|
|
|
|
|
int evp_is_a(OSSL_PROVIDER *prov, int number, const char *name)
|
|
|
|
{
|
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
return ossl_namemap_name2num(namemap, name) == number;
|
|
|
|
}
|
2019-09-22 02:57:51 +08:00
|
|
|
|
2019-09-23 16:56:13 +08:00
|
|
|
void evp_names_do_all(OSSL_PROVIDER *prov, int number,
|
|
|
|
void (*fn)(const char *name, void *data),
|
|
|
|
void *data)
|
2019-09-22 02:57:51 +08:00
|
|
|
{
|
|
|
|
OPENSSL_CTX *libctx = ossl_provider_library_context(prov);
|
|
|
|
OSSL_NAMEMAP *namemap = ossl_namemap_stored(libctx);
|
|
|
|
|
|
|
|
ossl_namemap_doall_names(namemap, number, fn, data);
|
|
|
|
}
|