2019-05-27 06:55:01 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2016-06-22 16:49:13 +00:00
|
|
|
/*
|
|
|
|
* Key-agreement Protocol Primitives (KPP)
|
|
|
|
*
|
|
|
|
* Copyright (c) 2016, Intel Corporation
|
|
|
|
* Authors: Salvatore Benedetto <salvatore.benedetto@intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _CRYPTO_KPP_
|
|
|
|
#define _CRYPTO_KPP_
|
2023-02-16 10:35:19 +00:00
|
|
|
|
|
|
|
#include <linux/atomic.h>
|
|
|
|
#include <linux/container_of.h>
|
2016-06-22 16:49:13 +00:00
|
|
|
#include <linux/crypto.h>
|
2023-02-16 10:35:19 +00:00
|
|
|
#include <linux/slab.h>
|
2016-06-22 16:49:13 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* struct kpp_request
|
|
|
|
*
|
|
|
|
* @base: Common attributes for async crypto requests
|
|
|
|
* @src: Source data
|
|
|
|
* @dst: Destination data
|
|
|
|
* @src_len: Size of the input buffer
|
|
|
|
* @dst_len: Size of the output buffer. It needs to be at least
|
|
|
|
* as big as the expected result depending on the operation
|
|
|
|
* After operation it will be updated with the actual size of the
|
|
|
|
* result. In case of error where the dst sgl size was insufficient,
|
|
|
|
* it will be updated to the size required for the operation.
|
|
|
|
* @__ctx: Start of private context data
|
|
|
|
*/
|
|
|
|
struct kpp_request {
|
|
|
|
struct crypto_async_request base;
|
|
|
|
struct scatterlist *src;
|
|
|
|
struct scatterlist *dst;
|
|
|
|
unsigned int src_len;
|
|
|
|
unsigned int dst_len;
|
|
|
|
void *__ctx[] CRYPTO_MINALIGN_ATTR;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct crypto_kpp - user-instantiated object which encapsulate
|
|
|
|
* algorithms and core processing logic
|
|
|
|
*
|
2022-11-22 10:09:16 +00:00
|
|
|
* @reqsize: Request context size required by algorithm
|
|
|
|
* implementation
|
2016-06-22 16:49:13 +00:00
|
|
|
* @base: Common crypto API algorithm data structure
|
|
|
|
*/
|
|
|
|
struct crypto_kpp {
|
2022-11-22 10:09:16 +00:00
|
|
|
unsigned int reqsize;
|
|
|
|
|
2016-06-22 16:49:13 +00:00
|
|
|
struct crypto_tfm base;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct kpp_alg - generic key-agreement protocol primitives
|
|
|
|
*
|
|
|
|
* @set_secret: Function invokes the protocol specific function to
|
|
|
|
* store the secret private key along with parameters.
|
2017-05-25 07:18:03 +00:00
|
|
|
* The implementation knows how to decode the buffer
|
2016-06-22 16:49:13 +00:00
|
|
|
* @generate_public_key: Function generate the public key to be sent to the
|
|
|
|
* counterpart. In case of error, where output is not big
|
|
|
|
* enough req->dst_len will be updated to the size
|
|
|
|
* required
|
|
|
|
* @compute_shared_secret: Function compute the shared secret as defined by
|
|
|
|
* the algorithm. The result is given back to the user.
|
|
|
|
* In case of error, where output is not big enough,
|
|
|
|
* req->dst_len will be updated to the size required
|
|
|
|
* @max_size: Function returns the size of the output buffer
|
|
|
|
* @init: Initialize the object. This is called only once at
|
|
|
|
* instantiation time. In case the cryptographic hardware
|
|
|
|
* needs to be initialized. Software fallback should be
|
|
|
|
* put in place here.
|
|
|
|
* @exit: Undo everything @init did.
|
|
|
|
*
|
2016-10-21 02:58:20 +00:00
|
|
|
* @base: Common crypto API algorithm data structure
|
2016-06-22 16:49:13 +00:00
|
|
|
*/
|
|
|
|
struct kpp_alg {
|
2017-02-24 23:46:58 +00:00
|
|
|
int (*set_secret)(struct crypto_kpp *tfm, const void *buffer,
|
2016-06-22 16:49:13 +00:00
|
|
|
unsigned int len);
|
|
|
|
int (*generate_public_key)(struct kpp_request *req);
|
|
|
|
int (*compute_shared_secret)(struct kpp_request *req);
|
|
|
|
|
2017-05-25 07:18:08 +00:00
|
|
|
unsigned int (*max_size)(struct crypto_kpp *tfm);
|
2016-06-22 16:49:13 +00:00
|
|
|
|
|
|
|
int (*init)(struct crypto_kpp *tfm);
|
|
|
|
void (*exit)(struct crypto_kpp *tfm);
|
|
|
|
|
|
|
|
struct crypto_alg base;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2016-10-21 02:58:20 +00:00
|
|
|
* DOC: Generic Key-agreement Protocol Primitives API
|
2016-06-22 16:49:13 +00:00
|
|
|
*
|
|
|
|
* The KPP API is used with the algorithm type
|
|
|
|
* CRYPTO_ALG_TYPE_KPP (listed as type "kpp" in /proc/crypto)
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_alloc_kpp() - allocate KPP tfm handle
|
|
|
|
* @alg_name: is the name of the kpp algorithm (e.g. "dh", "ecdh")
|
|
|
|
* @type: specifies the type of the algorithm
|
|
|
|
* @mask: specifies the mask for the algorithm
|
|
|
|
*
|
|
|
|
* Allocate a handle for kpp algorithm. The returned struct crypto_kpp
|
2017-05-25 07:18:03 +00:00
|
|
|
* is required for any following API invocation
|
2016-06-22 16:49:13 +00:00
|
|
|
*
|
|
|
|
* Return: allocated handle in case of success; IS_ERR() is true in case of
|
|
|
|
* an error, PTR_ERR() returns the error code.
|
|
|
|
*/
|
|
|
|
struct crypto_kpp *crypto_alloc_kpp(const char *alg_name, u32 type, u32 mask);
|
|
|
|
|
2022-06-27 09:51:58 +00:00
|
|
|
int crypto_has_kpp(const char *alg_name, u32 type, u32 mask);
|
|
|
|
|
2016-06-22 16:49:13 +00:00
|
|
|
static inline struct crypto_tfm *crypto_kpp_tfm(struct crypto_kpp *tfm)
|
|
|
|
{
|
|
|
|
return &tfm->base;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct kpp_alg *__crypto_kpp_alg(struct crypto_alg *alg)
|
|
|
|
{
|
|
|
|
return container_of(alg, struct kpp_alg, base);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct crypto_kpp *__crypto_kpp_tfm(struct crypto_tfm *tfm)
|
|
|
|
{
|
|
|
|
return container_of(tfm, struct crypto_kpp, base);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct kpp_alg *crypto_kpp_alg(struct crypto_kpp *tfm)
|
|
|
|
{
|
|
|
|
return __crypto_kpp_alg(crypto_kpp_tfm(tfm)->__crt_alg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned int crypto_kpp_reqsize(struct crypto_kpp *tfm)
|
|
|
|
{
|
2022-11-22 10:09:16 +00:00
|
|
|
return tfm->reqsize;
|
2016-06-22 16:49:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void kpp_request_set_tfm(struct kpp_request *req,
|
|
|
|
struct crypto_kpp *tfm)
|
|
|
|
{
|
|
|
|
req->base.tfm = crypto_kpp_tfm(tfm);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct crypto_kpp *crypto_kpp_reqtfm(struct kpp_request *req)
|
|
|
|
{
|
|
|
|
return __crypto_kpp_tfm(req->base.tfm);
|
|
|
|
}
|
|
|
|
|
2017-07-05 10:07:58 +00:00
|
|
|
static inline u32 crypto_kpp_get_flags(struct crypto_kpp *tfm)
|
|
|
|
{
|
|
|
|
return crypto_tfm_get_flags(crypto_kpp_tfm(tfm));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void crypto_kpp_set_flags(struct crypto_kpp *tfm, u32 flags)
|
|
|
|
{
|
|
|
|
crypto_tfm_set_flags(crypto_kpp_tfm(tfm), flags);
|
|
|
|
}
|
|
|
|
|
2016-06-22 16:49:13 +00:00
|
|
|
/**
|
|
|
|
* crypto_free_kpp() - free KPP tfm handle
|
|
|
|
*
|
|
|
|
* @tfm: KPP tfm handle allocated with crypto_alloc_kpp()
|
2021-03-02 20:33:03 +00:00
|
|
|
*
|
|
|
|
* If @tfm is a NULL or error pointer, this function does nothing.
|
2016-06-22 16:49:13 +00:00
|
|
|
*/
|
|
|
|
static inline void crypto_free_kpp(struct crypto_kpp *tfm)
|
|
|
|
{
|
|
|
|
crypto_destroy_tfm(tfm, crypto_kpp_tfm(tfm));
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kpp_request_alloc() - allocates kpp request
|
|
|
|
*
|
|
|
|
* @tfm: KPP tfm handle allocated with crypto_alloc_kpp()
|
|
|
|
* @gfp: allocation flags
|
|
|
|
*
|
|
|
|
* Return: allocated handle in case of success or NULL in case of an error.
|
|
|
|
*/
|
|
|
|
static inline struct kpp_request *kpp_request_alloc(struct crypto_kpp *tfm,
|
|
|
|
gfp_t gfp)
|
|
|
|
{
|
|
|
|
struct kpp_request *req;
|
|
|
|
|
|
|
|
req = kmalloc(sizeof(*req) + crypto_kpp_reqsize(tfm), gfp);
|
|
|
|
if (likely(req))
|
|
|
|
kpp_request_set_tfm(req, tfm);
|
|
|
|
|
|
|
|
return req;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kpp_request_free() - zeroize and free kpp request
|
|
|
|
*
|
|
|
|
* @req: request to free
|
|
|
|
*/
|
|
|
|
static inline void kpp_request_free(struct kpp_request *req)
|
|
|
|
{
|
2020-08-07 06:18:13 +00:00
|
|
|
kfree_sensitive(req);
|
2016-06-22 16:49:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kpp_request_set_callback() - Sets an asynchronous callback.
|
|
|
|
*
|
|
|
|
* Callback will be called when an asynchronous operation on a given
|
|
|
|
* request is finished.
|
|
|
|
*
|
|
|
|
* @req: request that the callback will be set for
|
|
|
|
* @flgs: specify for instance if the operation may backlog
|
|
|
|
* @cmpl: callback which will be called
|
|
|
|
* @data: private data used by the caller
|
|
|
|
*/
|
|
|
|
static inline void kpp_request_set_callback(struct kpp_request *req,
|
|
|
|
u32 flgs,
|
|
|
|
crypto_completion_t cmpl,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
req->base.complete = cmpl;
|
|
|
|
req->base.data = data;
|
|
|
|
req->base.flags = flgs;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kpp_request_set_input() - Sets input buffer
|
|
|
|
*
|
|
|
|
* Sets parameters required by generate_public_key
|
|
|
|
*
|
|
|
|
* @req: kpp request
|
|
|
|
* @input: ptr to input scatter list
|
|
|
|
* @input_len: size of the input scatter list
|
|
|
|
*/
|
|
|
|
static inline void kpp_request_set_input(struct kpp_request *req,
|
|
|
|
struct scatterlist *input,
|
|
|
|
unsigned int input_len)
|
|
|
|
{
|
|
|
|
req->src = input;
|
|
|
|
req->src_len = input_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* kpp_request_set_output() - Sets output buffer
|
|
|
|
*
|
|
|
|
* Sets parameters required by kpp operation
|
|
|
|
*
|
|
|
|
* @req: kpp request
|
|
|
|
* @output: ptr to output scatter list
|
|
|
|
* @output_len: size of the output scatter list
|
|
|
|
*/
|
|
|
|
static inline void kpp_request_set_output(struct kpp_request *req,
|
|
|
|
struct scatterlist *output,
|
|
|
|
unsigned int output_len)
|
|
|
|
{
|
|
|
|
req->dst = output;
|
|
|
|
req->dst_len = output_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum {
|
|
|
|
CRYPTO_KPP_SECRET_TYPE_UNKNOWN,
|
2016-06-22 16:49:14 +00:00
|
|
|
CRYPTO_KPP_SECRET_TYPE_DH,
|
2016-06-22 16:49:15 +00:00
|
|
|
CRYPTO_KPP_SECRET_TYPE_ECDH,
|
2016-06-22 16:49:13 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct kpp_secret - small header for packing secret buffer
|
|
|
|
*
|
|
|
|
* @type: define type of secret. Each kpp type will define its own
|
|
|
|
* @len: specify the len of the secret, include the header, that
|
|
|
|
* follows the struct
|
|
|
|
*/
|
|
|
|
struct kpp_secret {
|
|
|
|
unsigned short type;
|
|
|
|
unsigned short len;
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_kpp_set_secret() - Invoke kpp operation
|
|
|
|
*
|
|
|
|
* Function invokes the specific kpp operation for a given alg.
|
|
|
|
*
|
|
|
|
* @tfm: tfm handle
|
2016-10-21 02:58:20 +00:00
|
|
|
* @buffer: Buffer holding the packet representation of the private
|
|
|
|
* key. The structure of the packet key depends on the particular
|
|
|
|
* KPP implementation. Packing and unpacking helpers are provided
|
|
|
|
* for ECDH and DH (see the respective header files for those
|
|
|
|
* implementations).
|
|
|
|
* @len: Length of the packet private key buffer.
|
2016-06-22 16:49:13 +00:00
|
|
|
*
|
|
|
|
* Return: zero on success; error code in case of error
|
|
|
|
*/
|
2017-02-24 23:46:58 +00:00
|
|
|
static inline int crypto_kpp_set_secret(struct crypto_kpp *tfm,
|
|
|
|
const void *buffer, unsigned int len)
|
2016-06-22 16:49:13 +00:00
|
|
|
{
|
crypto: remove CONFIG_CRYPTO_STATS
Remove support for the "Crypto usage statistics" feature
(CONFIG_CRYPTO_STATS). This feature does not appear to have ever been
used, and it is harmful because it significantly reduces performance and
is a large maintenance burden.
Covering each of these points in detail:
1. Feature is not being used
Since these generic crypto statistics are only readable using netlink,
it's fairly straightforward to look for programs that use them. I'm
unable to find any evidence that any such programs exist. For example,
Debian Code Search returns no hits except the kernel header and kernel
code itself and translations of the kernel header:
https://codesearch.debian.net/search?q=CRYPTOCFGA_STAT&literal=1&perpkg=1
The patch series that added this feature in 2018
(https://lore.kernel.org/linux-crypto/1537351855-16618-1-git-send-email-clabbe@baylibre.com/)
said "The goal is to have an ifconfig for crypto device." This doesn't
appear to have happened.
It's not clear that there is real demand for crypto statistics. Just
because the kernel provides other types of statistics such as I/O and
networking statistics and some people find those useful does not mean
that crypto statistics are useful too.
Further evidence that programs are not using CONFIG_CRYPTO_STATS is that
it was able to be disabled in RHEL and Fedora as a bug fix
(https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2947).
Even further evidence comes from the fact that there are and have been
bugs in how the stats work, but they were never reported. For example,
before Linux v6.7 hash stats were double-counted in most cases.
There has also never been any documentation for this feature, so it
might be hard to use even if someone wanted to.
2. CONFIG_CRYPTO_STATS significantly reduces performance
Enabling CONFIG_CRYPTO_STATS significantly reduces the performance of
the crypto API, even if no program ever retrieves the statistics. This
primarily affects systems with a large number of CPUs. For example,
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039576 reported
that Lustre client encryption performance improved from 21.7GB/s to
48.2GB/s by disabling CONFIG_CRYPTO_STATS.
It can be argued that this means that CONFIG_CRYPTO_STATS should be
optimized with per-cpu counters similar to many of the networking
counters. But no one has done this in 5+ years. This is consistent
with the fact that the feature appears to be unused, so there seems to
be little interest in improving it as opposed to just disabling it.
It can be argued that because CONFIG_CRYPTO_STATS is off by default,
performance doesn't matter. But Linux distros tend to error on the side
of enabling options. The option is enabled in Ubuntu and Arch Linux,
and until recently was enabled in RHEL and Fedora (see above). So, even
just having the option available is harmful to users.
3. CONFIG_CRYPTO_STATS is a large maintenance burden
There are over 1000 lines of code associated with CONFIG_CRYPTO_STATS,
spread among 32 files. It significantly complicates much of the
implementation of the crypto API. After the initial submission, many
fixes and refactorings have consumed effort of multiple people to keep
this feature "working". We should be spending this effort elsewhere.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-03-13 03:48:21 +00:00
|
|
|
return crypto_kpp_alg(tfm)->set_secret(tfm, buffer, len);
|
2016-06-22 16:49:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_kpp_generate_public_key() - Invoke kpp operation
|
|
|
|
*
|
|
|
|
* Function invokes the specific kpp operation for generating the public part
|
2016-10-21 02:58:20 +00:00
|
|
|
* for a given kpp algorithm.
|
|
|
|
*
|
|
|
|
* To generate a private key, the caller should use a random number generator.
|
|
|
|
* The output of the requested length serves as the private key.
|
2016-06-22 16:49:13 +00:00
|
|
|
*
|
|
|
|
* @req: kpp key request
|
|
|
|
*
|
|
|
|
* Return: zero on success; error code in case of error
|
|
|
|
*/
|
|
|
|
static inline int crypto_kpp_generate_public_key(struct kpp_request *req)
|
|
|
|
{
|
|
|
|
struct crypto_kpp *tfm = crypto_kpp_reqtfm(req);
|
2023-02-16 10:35:19 +00:00
|
|
|
|
crypto: remove CONFIG_CRYPTO_STATS
Remove support for the "Crypto usage statistics" feature
(CONFIG_CRYPTO_STATS). This feature does not appear to have ever been
used, and it is harmful because it significantly reduces performance and
is a large maintenance burden.
Covering each of these points in detail:
1. Feature is not being used
Since these generic crypto statistics are only readable using netlink,
it's fairly straightforward to look for programs that use them. I'm
unable to find any evidence that any such programs exist. For example,
Debian Code Search returns no hits except the kernel header and kernel
code itself and translations of the kernel header:
https://codesearch.debian.net/search?q=CRYPTOCFGA_STAT&literal=1&perpkg=1
The patch series that added this feature in 2018
(https://lore.kernel.org/linux-crypto/1537351855-16618-1-git-send-email-clabbe@baylibre.com/)
said "The goal is to have an ifconfig for crypto device." This doesn't
appear to have happened.
It's not clear that there is real demand for crypto statistics. Just
because the kernel provides other types of statistics such as I/O and
networking statistics and some people find those useful does not mean
that crypto statistics are useful too.
Further evidence that programs are not using CONFIG_CRYPTO_STATS is that
it was able to be disabled in RHEL and Fedora as a bug fix
(https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2947).
Even further evidence comes from the fact that there are and have been
bugs in how the stats work, but they were never reported. For example,
before Linux v6.7 hash stats were double-counted in most cases.
There has also never been any documentation for this feature, so it
might be hard to use even if someone wanted to.
2. CONFIG_CRYPTO_STATS significantly reduces performance
Enabling CONFIG_CRYPTO_STATS significantly reduces the performance of
the crypto API, even if no program ever retrieves the statistics. This
primarily affects systems with a large number of CPUs. For example,
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039576 reported
that Lustre client encryption performance improved from 21.7GB/s to
48.2GB/s by disabling CONFIG_CRYPTO_STATS.
It can be argued that this means that CONFIG_CRYPTO_STATS should be
optimized with per-cpu counters similar to many of the networking
counters. But no one has done this in 5+ years. This is consistent
with the fact that the feature appears to be unused, so there seems to
be little interest in improving it as opposed to just disabling it.
It can be argued that because CONFIG_CRYPTO_STATS is off by default,
performance doesn't matter. But Linux distros tend to error on the side
of enabling options. The option is enabled in Ubuntu and Arch Linux,
and until recently was enabled in RHEL and Fedora (see above). So, even
just having the option available is harmful to users.
3. CONFIG_CRYPTO_STATS is a large maintenance burden
There are over 1000 lines of code associated with CONFIG_CRYPTO_STATS,
spread among 32 files. It significantly complicates much of the
implementation of the crypto API. After the initial submission, many
fixes and refactorings have consumed effort of multiple people to keep
this feature "working". We should be spending this effort elsewhere.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-03-13 03:48:21 +00:00
|
|
|
return crypto_kpp_alg(tfm)->generate_public_key(req);
|
2016-06-22 16:49:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_kpp_compute_shared_secret() - Invoke kpp operation
|
|
|
|
*
|
|
|
|
* Function invokes the specific kpp operation for computing the shared secret
|
|
|
|
* for a given kpp algorithm.
|
|
|
|
*
|
|
|
|
* @req: kpp key request
|
|
|
|
*
|
|
|
|
* Return: zero on success; error code in case of error
|
|
|
|
*/
|
|
|
|
static inline int crypto_kpp_compute_shared_secret(struct kpp_request *req)
|
|
|
|
{
|
|
|
|
struct crypto_kpp *tfm = crypto_kpp_reqtfm(req);
|
2023-02-16 10:35:19 +00:00
|
|
|
|
crypto: remove CONFIG_CRYPTO_STATS
Remove support for the "Crypto usage statistics" feature
(CONFIG_CRYPTO_STATS). This feature does not appear to have ever been
used, and it is harmful because it significantly reduces performance and
is a large maintenance burden.
Covering each of these points in detail:
1. Feature is not being used
Since these generic crypto statistics are only readable using netlink,
it's fairly straightforward to look for programs that use them. I'm
unable to find any evidence that any such programs exist. For example,
Debian Code Search returns no hits except the kernel header and kernel
code itself and translations of the kernel header:
https://codesearch.debian.net/search?q=CRYPTOCFGA_STAT&literal=1&perpkg=1
The patch series that added this feature in 2018
(https://lore.kernel.org/linux-crypto/1537351855-16618-1-git-send-email-clabbe@baylibre.com/)
said "The goal is to have an ifconfig for crypto device." This doesn't
appear to have happened.
It's not clear that there is real demand for crypto statistics. Just
because the kernel provides other types of statistics such as I/O and
networking statistics and some people find those useful does not mean
that crypto statistics are useful too.
Further evidence that programs are not using CONFIG_CRYPTO_STATS is that
it was able to be disabled in RHEL and Fedora as a bug fix
(https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2947).
Even further evidence comes from the fact that there are and have been
bugs in how the stats work, but they were never reported. For example,
before Linux v6.7 hash stats were double-counted in most cases.
There has also never been any documentation for this feature, so it
might be hard to use even if someone wanted to.
2. CONFIG_CRYPTO_STATS significantly reduces performance
Enabling CONFIG_CRYPTO_STATS significantly reduces the performance of
the crypto API, even if no program ever retrieves the statistics. This
primarily affects systems with a large number of CPUs. For example,
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039576 reported
that Lustre client encryption performance improved from 21.7GB/s to
48.2GB/s by disabling CONFIG_CRYPTO_STATS.
It can be argued that this means that CONFIG_CRYPTO_STATS should be
optimized with per-cpu counters similar to many of the networking
counters. But no one has done this in 5+ years. This is consistent
with the fact that the feature appears to be unused, so there seems to
be little interest in improving it as opposed to just disabling it.
It can be argued that because CONFIG_CRYPTO_STATS is off by default,
performance doesn't matter. But Linux distros tend to error on the side
of enabling options. The option is enabled in Ubuntu and Arch Linux,
and until recently was enabled in RHEL and Fedora (see above). So, even
just having the option available is harmful to users.
3. CONFIG_CRYPTO_STATS is a large maintenance burden
There are over 1000 lines of code associated with CONFIG_CRYPTO_STATS,
spread among 32 files. It significantly complicates much of the
implementation of the crypto API. After the initial submission, many
fixes and refactorings have consumed effort of multiple people to keep
this feature "working". We should be spending this effort elsewhere.
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-03-13 03:48:21 +00:00
|
|
|
return crypto_kpp_alg(tfm)->compute_shared_secret(req);
|
2016-06-22 16:49:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* crypto_kpp_maxsize() - Get len for output buffer
|
|
|
|
*
|
2017-05-25 07:18:08 +00:00
|
|
|
* Function returns the output buffer size required for a given key.
|
|
|
|
* Function assumes that the key is already set in the transformation. If this
|
|
|
|
* function is called without a setkey or with a failed setkey, you will end up
|
|
|
|
* in a NULL dereference.
|
2016-06-22 16:49:13 +00:00
|
|
|
*
|
|
|
|
* @tfm: KPP tfm handle allocated with crypto_alloc_kpp()
|
|
|
|
*/
|
2017-05-25 07:18:08 +00:00
|
|
|
static inline unsigned int crypto_kpp_maxsize(struct crypto_kpp *tfm)
|
2016-06-22 16:49:13 +00:00
|
|
|
{
|
|
|
|
struct kpp_alg *alg = crypto_kpp_alg(tfm);
|
|
|
|
|
|
|
|
return alg->max_size(tfm);
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|