Update Linux to v5.10.109
Sourced from [1]
[1] https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.109.tar.xz
Change-Id: I19bca9fc6762d4e63bcf3e4cba88bbe560d9c76c
Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
diff --git a/Documentation/crypto/api-intro.txt b/Documentation/crypto/api-intro.rst
similarity index 69%
rename from Documentation/crypto/api-intro.txt
rename to Documentation/crypto/api-intro.rst
index 45d943f..15201be 100644
--- a/Documentation/crypto/api-intro.txt
+++ b/Documentation/crypto/api-intro.rst
@@ -1,7 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
- Scatterlist Cryptographic API
-
-INTRODUCTION
+=============================
+Scatterlist Cryptographic API
+=============================
+
+Introduction
+============
The Scatterlist Crypto API takes page vectors (scatterlists) as
arguments, and works directly on pages. In some cases (e.g. ECB
@@ -13,22 +17,23 @@
for linearization.
-DETAILS
+Details
+=======
At the lowest level are algorithms, which register dynamically with the
API.
'Transforms' are user-instantiated objects, which maintain state, handle all
-of the implementation logic (e.g. manipulating page vectors) and provide an
-abstraction to the underlying algorithms. However, at the user
+of the implementation logic (e.g. manipulating page vectors) and provide an
+abstraction to the underlying algorithms. However, at the user
level they are very simple.
-Conceptually, the API layering looks like this:
+Conceptually, the API layering looks like this::
[transform api] (user interface)
[transform ops] (per-type logic glue e.g. cipher.c, compress.c)
[algorithm api] (for registering algorithms)
-
+
The idea is to make the user interface and algorithm registration API
very simple, while hiding the core logic from both. Many good ideas
from existing APIs such as Cryptoapi and Nettle have been adapted for this.
@@ -44,21 +49,21 @@
subject to block size requirements (i.e., non-stream ciphers can only
process multiples of blocks).
-Here's an example of how to use the API:
+Here's an example of how to use the API::
#include <crypto/hash.h>
#include <linux/err.h>
#include <linux/scatterlist.h>
-
+
struct scatterlist sg[2];
char result[128];
struct crypto_ahash *tfm;
struct ahash_request *req;
-
+
tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
fail();
-
+
/* ... set up the scatterlists ... */
req = ahash_request_alloc(tfm, GFP_ATOMIC);
@@ -67,18 +72,19 @@
ahash_request_set_callback(req, 0, NULL, NULL);
ahash_request_set_crypt(req, sg, result, 2);
-
+
if (crypto_ahash_digest(req))
fail();
ahash_request_free(req);
crypto_free_ahash(tfm);
-
+
Many real examples are available in the regression test module (tcrypt.c).
-DEVELOPER NOTES
+Developer Notes
+===============
Transforms may only be allocated in user context, and cryptographic
methods may only be called from softirq and user contexts. For
@@ -91,7 +97,8 @@
across non-aligned page fragment boundaries.
-ADDING NEW ALGORITHMS
+Adding New Algorithms
+=====================
When submitting a new algorithm for inclusion, a mandatory requirement
is that at least a few test vectors from known sources (preferably
@@ -119,132 +126,137 @@
might already be working on.
-BUGS
+Bugs
+====
Send bug reports to:
-linux-crypto@vger.kernel.org
-Cc: Herbert Xu <herbert@gondor.apana.org.au>,
+ linux-crypto@vger.kernel.org
+
+Cc:
+ Herbert Xu <herbert@gondor.apana.org.au>,
David S. Miller <davem@redhat.com>
-FURTHER INFORMATION
+Further Information
+===================
For further patches and various updates, including the current TODO
list, see:
http://gondor.apana.org.au/~herbert/crypto/
-AUTHORS
+Authors
+=======
-James Morris
-David S. Miller
-Herbert Xu
+- James Morris
+- David S. Miller
+- Herbert Xu
-CREDITS
+Credits
+=======
The following people provided invaluable feedback during the development
of the API:
- Alexey Kuznetzov
- Rusty Russell
- Herbert Valerio Riedel
- Jeff Garzik
- Michael Richardson
- Andrew Morton
- Ingo Oeser
- Christoph Hellwig
+ - Alexey Kuznetzov
+ - Rusty Russell
+ - Herbert Valerio Riedel
+ - Jeff Garzik
+ - Michael Richardson
+ - Andrew Morton
+ - Ingo Oeser
+ - Christoph Hellwig
Portions of this API were derived from the following projects:
-
+
Kerneli Cryptoapi (http://www.kerneli.org/)
- Alexander Kjeldaas
- Herbert Valerio Riedel
- Kyle McMartin
- Jean-Luc Cooke
- David Bryson
- Clemens Fruhwirth
- Tobias Ringstrom
- Harald Welte
+ - Alexander Kjeldaas
+ - Herbert Valerio Riedel
+ - Kyle McMartin
+ - Jean-Luc Cooke
+ - David Bryson
+ - Clemens Fruhwirth
+ - Tobias Ringstrom
+ - Harald Welte
and;
-
- Nettle (http://www.lysator.liu.se/~nisse/nettle/)
- Niels Möller
+
+ Nettle (https://www.lysator.liu.se/~nisse/nettle/)
+ - Niels Möller
Original developers of the crypto algorithms:
- Dana L. How (DES)
- Andrew Tridgell and Steve French (MD4)
- Colin Plumb (MD5)
- Steve Reid (SHA1)
- Jean-Luc Cooke (SHA256, SHA384, SHA512)
- Kazunori Miyazawa / USAGI (HMAC)
- Matthew Skala (Twofish)
- Dag Arne Osvik (Serpent)
- Brian Gladman (AES)
- Kartikey Mahendra Bhatt (CAST6)
- Jon Oberheide (ARC4)
- Jouni Malinen (Michael MIC)
- NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
+ - Dana L. How (DES)
+ - Andrew Tridgell and Steve French (MD4)
+ - Colin Plumb (MD5)
+ - Steve Reid (SHA1)
+ - Jean-Luc Cooke (SHA256, SHA384, SHA512)
+ - Kazunori Miyazawa / USAGI (HMAC)
+ - Matthew Skala (Twofish)
+ - Dag Arne Osvik (Serpent)
+ - Brian Gladman (AES)
+ - Kartikey Mahendra Bhatt (CAST6)
+ - Jon Oberheide (ARC4)
+ - Jouni Malinen (Michael MIC)
+ - NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
SHA1 algorithm contributors:
- Jean-Francois Dive
-
+ - Jean-Francois Dive
+
DES algorithm contributors:
- Raimar Falke
- Gisle Sælensminde
- Niels Möller
+ - Raimar Falke
+ - Gisle Sælensminde
+ - Niels Möller
Blowfish algorithm contributors:
- Herbert Valerio Riedel
- Kyle McMartin
+ - Herbert Valerio Riedel
+ - Kyle McMartin
Twofish algorithm contributors:
- Werner Koch
- Marc Mutz
+ - Werner Koch
+ - Marc Mutz
SHA256/384/512 algorithm contributors:
- Andrew McDonald
- Kyle McMartin
- Herbert Valerio Riedel
-
+ - Andrew McDonald
+ - Kyle McMartin
+ - Herbert Valerio Riedel
+
AES algorithm contributors:
- Alexander Kjeldaas
- Herbert Valerio Riedel
- Kyle McMartin
- Adam J. Richter
- Fruhwirth Clemens (i586)
- Linus Torvalds (i586)
+ - Alexander Kjeldaas
+ - Herbert Valerio Riedel
+ - Kyle McMartin
+ - Adam J. Richter
+ - Fruhwirth Clemens (i586)
+ - Linus Torvalds (i586)
CAST5 algorithm contributors:
- Kartikey Mahendra Bhatt (original developers unknown, FSF copyright).
+ - Kartikey Mahendra Bhatt (original developers unknown, FSF copyright).
TEA/XTEA algorithm contributors:
- Aaron Grothe
- Michael Ringe
+ - Aaron Grothe
+ - Michael Ringe
Khazad algorithm contributors:
- Aaron Grothe
+ - Aaron Grothe
Whirlpool algorithm contributors:
- Aaron Grothe
- Jean-Luc Cooke
+ - Aaron Grothe
+ - Jean-Luc Cooke
Anubis algorithm contributors:
- Aaron Grothe
+ - Aaron Grothe
Tiger algorithm contributors:
- Aaron Grothe
+ - Aaron Grothe
VIA PadLock contributors:
- Michal Ludvig
+ - Michal Ludvig
Camellia algorithm contributors:
- NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
+ - NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
Generic scatterwalk code by Adam J. Richter <adam@yggdrasil.com>
Please send any credits updates or corrections to:
Herbert Xu <herbert@gondor.apana.org.au>
-
diff --git a/Documentation/crypto/api-skcipher.rst b/Documentation/crypto/api-skcipher.rst
index 20ba08d..1aaf898 100644
--- a/Documentation/crypto/api-skcipher.rst
+++ b/Documentation/crypto/api-skcipher.rst
@@ -5,7 +5,7 @@
:doc: Block Cipher Algorithm Definitions
.. kernel-doc:: include/linux/crypto.h
- :functions: crypto_alg ablkcipher_alg blkcipher_alg cipher_alg compress_alg
+ :functions: crypto_alg cipher_alg compress_alg
Symmetric Key Cipher API
------------------------
@@ -33,30 +33,3 @@
.. kernel-doc:: include/linux/crypto.h
:functions: crypto_alloc_cipher crypto_free_cipher crypto_has_cipher crypto_cipher_blocksize crypto_cipher_setkey crypto_cipher_encrypt_one crypto_cipher_decrypt_one
-
-Asynchronous Block Cipher API - Deprecated
-------------------------------------------
-
-.. kernel-doc:: include/linux/crypto.h
- :doc: Asynchronous Block Cipher API
-
-.. kernel-doc:: include/linux/crypto.h
- :functions: crypto_free_ablkcipher crypto_has_ablkcipher crypto_ablkcipher_ivsize crypto_ablkcipher_blocksize crypto_ablkcipher_setkey crypto_ablkcipher_reqtfm crypto_ablkcipher_encrypt crypto_ablkcipher_decrypt
-
-Asynchronous Cipher Request Handle - Deprecated
------------------------------------------------
-
-.. kernel-doc:: include/linux/crypto.h
- :doc: Asynchronous Cipher Request Handle
-
-.. kernel-doc:: include/linux/crypto.h
- :functions: crypto_ablkcipher_reqsize ablkcipher_request_set_tfm ablkcipher_request_alloc ablkcipher_request_free ablkcipher_request_set_callback ablkcipher_request_set_crypt
-
-Synchronous Block Cipher API - Deprecated
------------------------------------------
-
-.. kernel-doc:: include/linux/crypto.h
- :doc: Synchronous Block Cipher API
-
-.. kernel-doc:: include/linux/crypto.h
- :functions: crypto_alloc_blkcipher crypto_free_blkcipher crypto_has_blkcipher crypto_blkcipher_name crypto_blkcipher_ivsize crypto_blkcipher_blocksize crypto_blkcipher_setkey crypto_blkcipher_encrypt crypto_blkcipher_encrypt_iv crypto_blkcipher_decrypt crypto_blkcipher_decrypt_iv crypto_blkcipher_set_iv crypto_blkcipher_get_iv
diff --git a/Documentation/crypto/architecture.rst b/Documentation/crypto/architecture.rst
index 3eae1ae..646c338 100644
--- a/Documentation/crypto/architecture.rst
+++ b/Documentation/crypto/architecture.rst
@@ -201,10 +201,6 @@
- CRYPTO_ALG_TYPE_AEAD Authenticated Encryption with Associated Data
(MAC)
-- CRYPTO_ALG_TYPE_BLKCIPHER Synchronous multi-block cipher
-
-- CRYPTO_ALG_TYPE_ABLKCIPHER Asynchronous multi-block cipher
-
- CRYPTO_ALG_TYPE_KPP Key-agreement Protocol Primitive (KPP) such as
an ECDH or DH implementation
diff --git a/Documentation/crypto/asymmetric-keys.txt b/Documentation/crypto/asymmetric-keys.rst
similarity index 90%
rename from Documentation/crypto/asymmetric-keys.txt
rename to Documentation/crypto/asymmetric-keys.rst
index 8763866..349f44a 100644
--- a/Documentation/crypto/asymmetric-keys.txt
+++ b/Documentation/crypto/asymmetric-keys.rst
@@ -1,8 +1,10 @@
- =============================================
- ASYMMETRIC / PUBLIC-KEY CRYPTOGRAPHY KEY TYPE
- =============================================
+.. SPDX-License-Identifier: GPL-2.0
-Contents:
+=============================================
+Asymmetric / Public-key Cryptography Key Type
+=============================================
+
+.. Contents:
- Overview.
- Key identification.
@@ -13,8 +15,7 @@
- Keyring link restrictions.
-========
-OVERVIEW
+Overview
========
The "asymmetric" key type is designed to be a container for the keys used in
@@ -42,8 +43,7 @@
system (for example, a TPM).
-==================
-KEY IDENTIFICATION
+Key Identification
==================
If a key is added with an empty name, the instantiation data parsers are given
@@ -57,49 +57,48 @@
comparisons than just the straightforward comparison of the description with
the criterion string:
- (1) If the criterion string is of the form "id:<hexdigits>" then the match
+ 1) If the criterion string is of the form "id:<hexdigits>" then the match
function will examine a key's fingerprint to see if the hex digits given
- after the "id:" match the tail. For instance:
+ after the "id:" match the tail. For instance::
keyctl search @s asymmetric id:5acc2142
- will match a key with fingerprint:
+ will match a key with fingerprint::
1A00 2040 7601 7889 DE11 882C 3823 04AD 5ACC 2142
- (2) If the criterion string is of the form "<subtype>:<hexdigits>" then the
+ 2) If the criterion string is of the form "<subtype>:<hexdigits>" then the
match will match the ID as in (1), but with the added restriction that
only keys of the specified subtype (e.g. tpm) will be matched. For
- instance:
+ instance::
keyctl search @s asymmetric tpm:5acc2142
Looking in /proc/keys, the last 8 hex digits of the key fingerprint are
-displayed, along with the subtype:
+displayed, along with the subtype::
1a39e171 I----- 1 perm 3f010000 0 0 asymmetric modsign.0: DSA 5acc2142 []
-=========================
-ACCESSING ASYMMETRIC KEYS
+Accessing Asymmetric Keys
=========================
For general access to asymmetric keys from within the kernel, the following
-inclusion is required:
+inclusion is required::
#include <crypto/public_key.h>
This gives access to functions for dealing with asymmetric / public keys.
Three enums are defined there for representing public-key cryptography
-algorithms:
+algorithms::
enum pkey_algo
-digest algorithms used by those:
+digest algorithms used by those::
enum pkey_hash_algo
-and key identifier representations:
+and key identifier representations::
enum pkey_id_type
@@ -110,25 +109,25 @@
The operations defined upon a key are:
- (1) Signature verification.
+ 1) Signature verification.
Other operations are possible (such as encryption) with the same key data
required for verification, but not currently supported, and others
(eg. decryption and signature generation) require extra key data.
-SIGNATURE VERIFICATION
+Signature Verification
----------------------
An operation is provided to perform cryptographic signature verification, using
-an asymmetric key to provide or to provide access to the public key.
+an asymmetric key to provide or to provide access to the public key::
int verify_signature(const struct key *key,
const struct public_key_signature *sig);
The caller must have already obtained the key from some source and can then use
it to check the signature. The caller must have parsed the signature and
-transferred the relevant bits to the structure pointed to by sig.
+transferred the relevant bits to the structure pointed to by sig::
struct public_key_signature {
u8 *digest;
@@ -159,8 +158,7 @@
if the key argument is the wrong type or is incompletely set up.
-=======================
-ASYMMETRIC KEY SUBTYPES
+Asymmetric Key Subtypes
=======================
Asymmetric keys have a subtype that defines the set of operations that can be
@@ -171,11 +169,11 @@
the data required for it. The asymmetric key retains a reference on the
subtype module.
-The subtype definition structure can be found in:
+The subtype definition structure can be found in::
#include <keys/asymmetric-subtype.h>
-and looks like the following:
+and looks like the following::
struct asymmetric_key_subtype {
struct module *owner;
@@ -198,39 +196,37 @@
There are a number of operations defined by the subtype:
- (1) describe().
+ 1) describe().
Mandatory. This allows the subtype to display something in /proc/keys
against the key. For instance the name of the public key algorithm type
could be displayed. The key type will display the tail of the key
identity string after this.
- (2) destroy().
+ 2) destroy().
Mandatory. This should free the memory associated with the key. The
asymmetric key will look after freeing the fingerprint and releasing the
reference on the subtype module.
- (3) query().
+ 3) query().
Mandatory. This is a function for querying the capabilities of a key.
- (4) eds_op().
+ 4) eds_op().
Optional. This is the entry point for the encryption, decryption and
signature creation operations (which are distinguished by the operation ID
in the parameter struct). The subtype may do anything it likes to
implement an operation, including offloading to hardware.
- (5) verify_signature().
+ 5) verify_signature().
Optional. This is the entry point for signature verification. The
subtype may do anything it likes to implement an operation, including
offloading to hardware.
-
-==========================
-INSTANTIATION DATA PARSERS
+Instantiation Data Parsers
==========================
The asymmetric key type doesn't generally want to store or to deal with a raw
@@ -254,11 +250,11 @@
During key instantiation each parser in the list is tried until one doesn't
return -EBADMSG.
-The parser definition structure can be found in:
+The parser definition structure can be found in::
#include <keys/asymmetric-parser.h>
-and looks like the following:
+and looks like the following::
struct asymmetric_key_parser {
struct module *owner;
@@ -273,7 +269,7 @@
There is currently only a single operation defined by the parser, and it is
mandatory:
- (1) parse().
+ 1) parse().
This is called to preparse the key from the key creation and update paths.
In particular, it is called during the key creation _before_ a key is
@@ -282,7 +278,7 @@
The caller passes a pointer to the following struct with all of the fields
cleared, except for data, datalen and quotalen [see
- Documentation/security/keys/core.rst].
+ Documentation/security/keys/core.rst]::
struct key_preparsed_payload {
char *description;
@@ -321,7 +317,7 @@
public-key algorithm such as RSA and DSA this will likely be a printable
hex version of the key's fingerprint.
-Functions are provided to register and unregister parsers:
+Functions are provided to register and unregister parsers::
int register_asymmetric_key_parser(struct asymmetric_key_parser *parser);
void unregister_asymmetric_key_parser(struct asymmetric_key_parser *subtype);
@@ -330,8 +326,7 @@
displaying in debugging messages.
-=========================
-KEYRING LINK RESTRICTIONS
+Keyring Link Restrictions
=========================
Keyrings created from userspace using add_key can be configured to check the
@@ -340,7 +335,7 @@
Several restriction methods are available:
- (1) Restrict using the kernel builtin trusted keyring
+ 1) Restrict using the kernel builtin trusted keyring
- Option string used with KEYCTL_RESTRICT_KEYRING:
- "builtin_trusted"
@@ -350,7 +345,7 @@
rejected. The ca_keys kernel parameter also affects which keys are used
for signature verification.
- (2) Restrict using the kernel builtin and secondary trusted keyrings
+ 2) Restrict using the kernel builtin and secondary trusted keyrings
- Option string used with KEYCTL_RESTRICT_KEYRING:
- "builtin_and_secondary_trusted"
@@ -361,7 +356,7 @@
kernel parameter also affects which keys are used for signature
verification.
- (3) Restrict using a separate key or keyring
+ 3) Restrict using a separate key or keyring
- Option string used with KEYCTL_RESTRICT_KEYRING:
- "key_or_keyring:<key or keyring serial number>[:chain]"
@@ -378,7 +373,7 @@
certificate in order (starting closest to the root) to a keyring. For
instance, one keyring can be populated with links to a set of root
certificates, with a separate, restricted keyring set up for each
- certificate chain to be validated:
+ certificate chain to be validated::
# Create and populate a keyring for root certificates
root_id=`keyctl add keyring root-certs "" @s`
@@ -400,7 +395,7 @@
one of the root certificates.
A single keyring can be used to verify a chain of signatures by
- restricting the keyring after linking the root certificate:
+ restricting the keyring after linking the root certificate::
# Create a keyring for the certificate chain and add the root
chain2_id=`keyctl add keyring chain2 "" @s`
diff --git a/Documentation/crypto/async-tx-api.rst b/Documentation/crypto/async-tx-api.rst
new file mode 100644
index 0000000..bfc7739
--- /dev/null
+++ b/Documentation/crypto/async-tx-api.rst
@@ -0,0 +1,270 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=====================================
+Asynchronous Transfers/Transforms API
+=====================================
+
+.. Contents
+
+ 1. INTRODUCTION
+
+ 2 GENEALOGY
+
+ 3 USAGE
+ 3.1 General format of the API
+ 3.2 Supported operations
+ 3.3 Descriptor management
+ 3.4 When does the operation execute?
+ 3.5 When does the operation complete?
+ 3.6 Constraints
+ 3.7 Example
+
+ 4 DMAENGINE DRIVER DEVELOPER NOTES
+ 4.1 Conformance points
+ 4.2 "My application needs exclusive control of hardware channels"
+
+ 5 SOURCE
+
+1. Introduction
+===============
+
+The async_tx API provides methods for describing a chain of asynchronous
+bulk memory transfers/transforms with support for inter-transactional
+dependencies. It is implemented as a dmaengine client that smooths over
+the details of different hardware offload engine implementations. Code
+that is written to the API can optimize for asynchronous operation and
+the API will fit the chain of operations to the available offload
+resources.
+
+2.Genealogy
+===========
+
+The API was initially designed to offload the memory copy and
+xor-parity-calculations of the md-raid5 driver using the offload engines
+present in the Intel(R) Xscale series of I/O processors. It also built
+on the 'dmaengine' layer developed for offloading memory copies in the
+network stack using Intel(R) I/OAT engines. The following design
+features surfaced as a result:
+
+1. implicit synchronous path: users of the API do not need to know if
+ the platform they are running on has offload capabilities. The
+ operation will be offloaded when an engine is available and carried out
+ in software otherwise.
+2. cross channel dependency chains: the API allows a chain of dependent
+ operations to be submitted, like xor->copy->xor in the raid5 case. The
+ API automatically handles cases where the transition from one operation
+ to another implies a hardware channel switch.
+3. dmaengine extensions to support multiple clients and operation types
+ beyond 'memcpy'
+
+3. Usage
+========
+
+3.1 General format of the API
+-----------------------------
+
+::
+
+ struct dma_async_tx_descriptor *
+ async_<operation>(<op specific parameters>, struct async_submit ctl *submit)
+
+3.2 Supported operations
+------------------------
+
+======== ====================================================================
+memcpy memory copy between a source and a destination buffer
+memset fill a destination buffer with a byte value
+xor xor a series of source buffers and write the result to a
+ destination buffer
+xor_val xor a series of source buffers and set a flag if the
+ result is zero. The implementation attempts to prevent
+ writes to memory
+pq generate the p+q (raid6 syndrome) from a series of source buffers
+pq_val validate that a p and or q buffer are in sync with a given series of
+ sources
+datap (raid6_datap_recov) recover a raid6 data block and the p block
+ from the given sources
+2data (raid6_2data_recov) recover 2 raid6 data blocks from the given
+ sources
+======== ====================================================================
+
+3.3 Descriptor management
+-------------------------
+
+The return value is non-NULL and points to a 'descriptor' when the operation
+has been queued to execute asynchronously. Descriptors are recycled
+resources, under control of the offload engine driver, to be reused as
+operations complete. When an application needs to submit a chain of
+operations it must guarantee that the descriptor is not automatically recycled
+before the dependency is submitted. This requires that all descriptors be
+acknowledged by the application before the offload engine driver is allowed to
+recycle (or free) the descriptor. A descriptor can be acked by one of the
+following methods:
+
+1. setting the ASYNC_TX_ACK flag if no child operations are to be submitted
+2. submitting an unacknowledged descriptor as a dependency to another
+ async_tx call will implicitly set the acknowledged state.
+3. calling async_tx_ack() on the descriptor.
+
+3.4 When does the operation execute?
+------------------------------------
+
+Operations do not immediately issue after return from the
+async_<operation> call. Offload engine drivers batch operations to
+improve performance by reducing the number of mmio cycles needed to
+manage the channel. Once a driver-specific threshold is met the driver
+automatically issues pending operations. An application can force this
+event by calling async_tx_issue_pending_all(). This operates on all
+channels since the application has no knowledge of channel to operation
+mapping.
+
+3.5 When does the operation complete?
+-------------------------------------
+
+There are two methods for an application to learn about the completion
+of an operation.
+
+1. Call dma_wait_for_async_tx(). This call causes the CPU to spin while
+ it polls for the completion of the operation. It handles dependency
+ chains and issuing pending operations.
+2. Specify a completion callback. The callback routine runs in tasklet
+ context if the offload engine driver supports interrupts, or it is
+ called in application context if the operation is carried out
+ synchronously in software. The callback can be set in the call to
+ async_<operation>, or when the application needs to submit a chain of
+ unknown length it can use the async_trigger_callback() routine to set a
+ completion interrupt/callback at the end of the chain.
+
+3.6 Constraints
+---------------
+
+1. Calls to async_<operation> are not permitted in IRQ context. Other
+ contexts are permitted provided constraint #2 is not violated.
+2. Completion callback routines cannot submit new operations. This
+ results in recursion in the synchronous case and spin_locks being
+ acquired twice in the asynchronous case.
+
+3.7 Example
+-----------
+
+Perform a xor->copy->xor operation where each operation depends on the
+result from the previous operation::
+
+ void callback(void *param)
+ {
+ struct completion *cmp = param;
+
+ complete(cmp);
+ }
+
+ void run_xor_copy_xor(struct page **xor_srcs,
+ int xor_src_cnt,
+ struct page *xor_dest,
+ size_t xor_len,
+ struct page *copy_src,
+ struct page *copy_dest,
+ size_t copy_len)
+ {
+ struct dma_async_tx_descriptor *tx;
+ addr_conv_t addr_conv[xor_src_cnt];
+ struct async_submit_ctl submit;
+ addr_conv_t addr_conv[NDISKS];
+ struct completion cmp;
+
+ init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL,
+ addr_conv);
+ tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit)
+
+ submit->depend_tx = tx;
+ tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit);
+
+ init_completion(&cmp);
+ init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx,
+ callback, &cmp, addr_conv);
+ tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit);
+
+ async_tx_issue_pending_all();
+
+ wait_for_completion(&cmp);
+ }
+
+See include/linux/async_tx.h for more information on the flags. See the
+ops_run_* and ops_complete_* routines in drivers/md/raid5.c for more
+implementation examples.
+
+4. Driver Development Notes
+===========================
+
+4.1 Conformance points
+----------------------
+
+There are a few conformance points required in dmaengine drivers to
+accommodate assumptions made by applications using the async_tx API:
+
+1. Completion callbacks are expected to happen in tasklet context
+2. dma_async_tx_descriptor fields are never manipulated in IRQ context
+3. Use async_tx_run_dependencies() in the descriptor clean up path to
+ handle submission of dependent operations
+
+4.2 "My application needs exclusive control of hardware channels"
+-----------------------------------------------------------------
+
+Primarily this requirement arises from cases where a DMA engine driver
+is being used to support device-to-memory operations. A channel that is
+performing these operations cannot, for many platform specific reasons,
+be shared. For these cases the dma_request_channel() interface is
+provided.
+
+The interface is::
+
+ struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
+ dma_filter_fn filter_fn,
+ void *filter_param);
+
+Where dma_filter_fn is defined as::
+
+ typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param);
+
+When the optional 'filter_fn' parameter is set to NULL
+dma_request_channel simply returns the first channel that satisfies the
+capability mask. Otherwise, when the mask parameter is insufficient for
+specifying the necessary channel, the filter_fn routine can be used to
+disposition the available channels in the system. The filter_fn routine
+is called once for each free channel in the system. Upon seeing a
+suitable channel filter_fn returns DMA_ACK which flags that channel to
+be the return value from dma_request_channel. A channel allocated via
+this interface is exclusive to the caller, until dma_release_channel()
+is called.
+
+The DMA_PRIVATE capability flag is used to tag dma devices that should
+not be used by the general-purpose allocator. It can be set at
+initialization time if it is known that a channel will always be
+private. Alternatively, it is set when dma_request_channel() finds an
+unused "public" channel.
+
+A couple caveats to note when implementing a driver and consumer:
+
+1. Once a channel has been privately allocated it will no longer be
+ considered by the general-purpose allocator even after a call to
+ dma_release_channel().
+2. Since capabilities are specified at the device level a dma_device
+ with multiple channels will either have all channels public, or all
+ channels private.
+
+5. Source
+---------
+
+include/linux/dmaengine.h:
+ core header file for DMA drivers and api users
+drivers/dma/dmaengine.c:
+ offload engine channel management routines
+drivers/dma/:
+ location for offload engine drivers
+include/linux/async_tx.h:
+ core header file for the async_tx api
+crypto/async_tx/async_tx.c:
+ async_tx interface to dmaengine and common code
+crypto/async_tx/async_memcpy.c:
+ copy offload
+crypto/async_tx/async_xor.c:
+ xor and xor zero sum offload
diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.txt
deleted file mode 100644
index 7bf1be2..0000000
--- a/Documentation/crypto/async-tx-api.txt
+++ /dev/null
@@ -1,225 +0,0 @@
- Asynchronous Transfers/Transforms API
-
-1 INTRODUCTION
-
-2 GENEALOGY
-
-3 USAGE
-3.1 General format of the API
-3.2 Supported operations
-3.3 Descriptor management
-3.4 When does the operation execute?
-3.5 When does the operation complete?
-3.6 Constraints
-3.7 Example
-
-4 DMAENGINE DRIVER DEVELOPER NOTES
-4.1 Conformance points
-4.2 "My application needs exclusive control of hardware channels"
-
-5 SOURCE
-
----
-
-1 INTRODUCTION
-
-The async_tx API provides methods for describing a chain of asynchronous
-bulk memory transfers/transforms with support for inter-transactional
-dependencies. It is implemented as a dmaengine client that smooths over
-the details of different hardware offload engine implementations. Code
-that is written to the API can optimize for asynchronous operation and
-the API will fit the chain of operations to the available offload
-resources.
-
-2 GENEALOGY
-
-The API was initially designed to offload the memory copy and
-xor-parity-calculations of the md-raid5 driver using the offload engines
-present in the Intel(R) Xscale series of I/O processors. It also built
-on the 'dmaengine' layer developed for offloading memory copies in the
-network stack using Intel(R) I/OAT engines. The following design
-features surfaced as a result:
-1/ implicit synchronous path: users of the API do not need to know if
- the platform they are running on has offload capabilities. The
- operation will be offloaded when an engine is available and carried out
- in software otherwise.
-2/ cross channel dependency chains: the API allows a chain of dependent
- operations to be submitted, like xor->copy->xor in the raid5 case. The
- API automatically handles cases where the transition from one operation
- to another implies a hardware channel switch.
-3/ dmaengine extensions to support multiple clients and operation types
- beyond 'memcpy'
-
-3 USAGE
-
-3.1 General format of the API:
-struct dma_async_tx_descriptor *
-async_<operation>(<op specific parameters>, struct async_submit ctl *submit)
-
-3.2 Supported operations:
-memcpy - memory copy between a source and a destination buffer
-memset - fill a destination buffer with a byte value
-xor - xor a series of source buffers and write the result to a
- destination buffer
-xor_val - xor a series of source buffers and set a flag if the
- result is zero. The implementation attempts to prevent
- writes to memory
-pq - generate the p+q (raid6 syndrome) from a series of source buffers
-pq_val - validate that a p and or q buffer are in sync with a given series of
- sources
-datap - (raid6_datap_recov) recover a raid6 data block and the p block
- from the given sources
-2data - (raid6_2data_recov) recover 2 raid6 data blocks from the given
- sources
-
-3.3 Descriptor management:
-The return value is non-NULL and points to a 'descriptor' when the operation
-has been queued to execute asynchronously. Descriptors are recycled
-resources, under control of the offload engine driver, to be reused as
-operations complete. When an application needs to submit a chain of
-operations it must guarantee that the descriptor is not automatically recycled
-before the dependency is submitted. This requires that all descriptors be
-acknowledged by the application before the offload engine driver is allowed to
-recycle (or free) the descriptor. A descriptor can be acked by one of the
-following methods:
-1/ setting the ASYNC_TX_ACK flag if no child operations are to be submitted
-2/ submitting an unacknowledged descriptor as a dependency to another
- async_tx call will implicitly set the acknowledged state.
-3/ calling async_tx_ack() on the descriptor.
-
-3.4 When does the operation execute?
-Operations do not immediately issue after return from the
-async_<operation> call. Offload engine drivers batch operations to
-improve performance by reducing the number of mmio cycles needed to
-manage the channel. Once a driver-specific threshold is met the driver
-automatically issues pending operations. An application can force this
-event by calling async_tx_issue_pending_all(). This operates on all
-channels since the application has no knowledge of channel to operation
-mapping.
-
-3.5 When does the operation complete?
-There are two methods for an application to learn about the completion
-of an operation.
-1/ Call dma_wait_for_async_tx(). This call causes the CPU to spin while
- it polls for the completion of the operation. It handles dependency
- chains and issuing pending operations.
-2/ Specify a completion callback. The callback routine runs in tasklet
- context if the offload engine driver supports interrupts, or it is
- called in application context if the operation is carried out
- synchronously in software. The callback can be set in the call to
- async_<operation>, or when the application needs to submit a chain of
- unknown length it can use the async_trigger_callback() routine to set a
- completion interrupt/callback at the end of the chain.
-
-3.6 Constraints:
-1/ Calls to async_<operation> are not permitted in IRQ context. Other
- contexts are permitted provided constraint #2 is not violated.
-2/ Completion callback routines cannot submit new operations. This
- results in recursion in the synchronous case and spin_locks being
- acquired twice in the asynchronous case.
-
-3.7 Example:
-Perform a xor->copy->xor operation where each operation depends on the
-result from the previous operation:
-
-void callback(void *param)
-{
- struct completion *cmp = param;
-
- complete(cmp);
-}
-
-void run_xor_copy_xor(struct page **xor_srcs,
- int xor_src_cnt,
- struct page *xor_dest,
- size_t xor_len,
- struct page *copy_src,
- struct page *copy_dest,
- size_t copy_len)
-{
- struct dma_async_tx_descriptor *tx;
- addr_conv_t addr_conv[xor_src_cnt];
- struct async_submit_ctl submit;
- addr_conv_t addr_conv[NDISKS];
- struct completion cmp;
-
- init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL,
- addr_conv);
- tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit)
-
- submit->depend_tx = tx;
- tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit);
-
- init_completion(&cmp);
- init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx,
- callback, &cmp, addr_conv);
- tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit);
-
- async_tx_issue_pending_all();
-
- wait_for_completion(&cmp);
-}
-
-See include/linux/async_tx.h for more information on the flags. See the
-ops_run_* and ops_complete_* routines in drivers/md/raid5.c for more
-implementation examples.
-
-4 DRIVER DEVELOPMENT NOTES
-
-4.1 Conformance points:
-There are a few conformance points required in dmaengine drivers to
-accommodate assumptions made by applications using the async_tx API:
-1/ Completion callbacks are expected to happen in tasklet context
-2/ dma_async_tx_descriptor fields are never manipulated in IRQ context
-3/ Use async_tx_run_dependencies() in the descriptor clean up path to
- handle submission of dependent operations
-
-4.2 "My application needs exclusive control of hardware channels"
-Primarily this requirement arises from cases where a DMA engine driver
-is being used to support device-to-memory operations. A channel that is
-performing these operations cannot, for many platform specific reasons,
-be shared. For these cases the dma_request_channel() interface is
-provided.
-
-The interface is:
-struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
- dma_filter_fn filter_fn,
- void *filter_param);
-
-Where dma_filter_fn is defined as:
-typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param);
-
-When the optional 'filter_fn' parameter is set to NULL
-dma_request_channel simply returns the first channel that satisfies the
-capability mask. Otherwise, when the mask parameter is insufficient for
-specifying the necessary channel, the filter_fn routine can be used to
-disposition the available channels in the system. The filter_fn routine
-is called once for each free channel in the system. Upon seeing a
-suitable channel filter_fn returns DMA_ACK which flags that channel to
-be the return value from dma_request_channel. A channel allocated via
-this interface is exclusive to the caller, until dma_release_channel()
-is called.
-
-The DMA_PRIVATE capability flag is used to tag dma devices that should
-not be used by the general-purpose allocator. It can be set at
-initialization time if it is known that a channel will always be
-private. Alternatively, it is set when dma_request_channel() finds an
-unused "public" channel.
-
-A couple caveats to note when implementing a driver and consumer:
-1/ Once a channel has been privately allocated it will no longer be
- considered by the general-purpose allocator even after a call to
- dma_release_channel().
-2/ Since capabilities are specified at the device level a dma_device
- with multiple channels will either have all channels public, or all
- channels private.
-
-5 SOURCE
-
-include/linux/dmaengine.h: core header file for DMA drivers and api users
-drivers/dma/dmaengine.c: offload engine channel management routines
-drivers/dma/: location for offload engine drivers
-include/linux/async_tx.h: core header file for the async_tx api
-crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code
-crypto/async_tx/async_memcpy.c: copy offload
-crypto/async_tx/async_xor.c: xor and xor zero sum offload
diff --git a/Documentation/crypto/crypto_engine.rst b/Documentation/crypto/crypto_engine.rst
index 3baa23c..25cf983 100644
--- a/Documentation/crypto/crypto_engine.rst
+++ b/Documentation/crypto/crypto_engine.rst
@@ -63,8 +63,6 @@
When your driver receives a crypto_request, you must to transfer it to
the crypto engine via one of:
-* crypto_transfer_ablkcipher_request_to_engine()
-
* crypto_transfer_aead_request_to_engine()
* crypto_transfer_akcipher_request_to_engine()
@@ -75,8 +73,6 @@
At the end of the request process, a call to one of the following functions is needed:
-* crypto_finalize_ablkcipher_request()
-
* crypto_finalize_aead_request()
* crypto_finalize_akcipher_request()
diff --git a/Documentation/crypto/descore-readme.txt b/Documentation/crypto/descore-readme.rst
similarity index 81%
rename from Documentation/crypto/descore-readme.txt
rename to Documentation/crypto/descore-readme.rst
index 16e9e63..45bd9c8 100644
--- a/Documentation/crypto/descore-readme.txt
+++ b/Documentation/crypto/descore-readme.rst
@@ -1,8 +1,20 @@
-Below is the original README file from the descore.shar package.
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===========================================
+Fast & Portable DES encryption & decryption
+===========================================
+
+.. note::
+
+ Below is the original README file from the descore.shar package,
+ converted to ReST format.
+
------------------------------------------------------------------------------
des - fast & portable DES encryption & decryption.
-Copyright (C) 1992 Dana L. How
+
+Copyright |copy| 1992 Dana L. How
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU Library General Public License as published by
@@ -20,13 +32,12 @@
Author's address: how@isl.stanford.edu
-$Id: README,v 1.15 1992/05/20 00:25:32 how E $
+.. README,v 1.15 1992/05/20 00:25:32 how E
-
-==>> To compile after untarring/unsharring, just `make' <<==
-
+==>> To compile after untarring/unsharring, just ``make`` <<==
This package was designed with the following goals:
+
1. Highest possible encryption/decryption PERFORMANCE.
2. PORTABILITY to any byte-addressable host with a 32bit unsigned C type
3. Plug-compatible replacement for KERBEROS's low-level routines.
@@ -36,7 +47,7 @@
71755.204@compuserve.com, sparked a number of these enhancements.
To more rapidly understand the code in this package, inspect desSmallFips.i
-(created by typing `make') BEFORE you tackle desCode.h. The latter is set
+(created by typing ``make``) BEFORE you tackle desCode.h. The latter is set
up in a parameterized fashion so it can easily be modified by speed-daemon
hackers in pursuit of that last microsecond. You will find it more
illuminating to inspect one specific implementation,
@@ -47,11 +58,13 @@
compile on a SPARCStation 1 (cc -O4, gcc -O2):
this code (byte-order independent):
- 30us per encryption (options: 64k tables, no IP/FP)
- 33us per encryption (options: 64k tables, FIPS standard bit ordering)
- 45us per encryption (options: 2k tables, no IP/FP)
- 48us per encryption (options: 2k tables, FIPS standard bit ordering)
- 275us to set a new key (uses 1k of key tables)
+
+ - 30us per encryption (options: 64k tables, no IP/FP)
+ - 33us per encryption (options: 64k tables, FIPS standard bit ordering)
+ - 45us per encryption (options: 2k tables, no IP/FP)
+ - 48us per encryption (options: 2k tables, FIPS standard bit ordering)
+ - 275us to set a new key (uses 1k of key tables)
+
this has the quickest encryption/decryption routines i've seen.
since i was interested in fast des filters rather than crypt(3)
and password cracking, i haven't really bothered yet to speed up
@@ -63,15 +76,20 @@
are highly variable because of cache effects).
kerberos des replacement from australia (version 1.95):
- 53us per encryption (uses 2k of tables)
- 96us to set a new key (uses 2.25k of key tables)
+
+ - 53us per encryption (uses 2k of tables)
+ - 96us to set a new key (uses 2.25k of key tables)
+
so despite the author's inclusion of some of the performance
improvements i had suggested to him, this package's
encryption/decryption is still slower on the sparc and 68000.
more specifically, 19-40% slower on the 68020 and 11-35% slower
on the sparc, depending on the compiler;
in full gory detail (ALT_ECB is a libdes variant):
+
+ =============== ============== =============== =================
compiler machine desCore libdes ALT_ECB slower by
+ =============== ============== =============== =================
gcc 2.1 -O2 Sun 3/110 304 uS 369.5uS 461.8uS 22%
cc -O1 Sun 3/110 336 uS 436.6uS 399.3uS 19%
cc -O2 Sun 3/110 360 uS 532.4uS 505.1uS 40%
@@ -79,10 +97,15 @@
gcc 2.1 -O2 Sun 4/50 48 uS 53.4uS 57.5uS 11%
cc -O2 Sun 4/50 48 uS 64.6uS 64.7uS 35%
cc -O4 Sun 4/50 48 uS 64.7uS 64.9uS 35%
+ =============== ============== =============== =================
+
(my time measurements are not as accurate as his).
+
the comments in my first release of desCore on version 1.92:
- 68us per encryption (uses 2k of tables)
- 96us to set a new key (uses 2.25k of key tables)
+
+ - 68us per encryption (uses 2k of tables)
+ - 96us to set a new key (uses 2.25k of key tables)
+
this is a very nice package which implements the most important
of the optimizations which i did in my encryption routines.
it's a bit weak on common low-level optimizations which is why
@@ -91,48 +114,60 @@
speed up the key-setting routines with impressive results.
(at some point i may do the same in my package). he also implements
the rest of the mit des library.
+
(code from eay@psych.psy.uq.oz.au via comp.sources.misc)
fast crypt(3) package from denmark:
+
the des routine here is buried inside a loop to do the
crypt function and i didn't feel like ripping it out and measuring
performance. his code takes 26 sparc instructions to compute one
des iteration; above, Quick (64k) takes 21 and Small (2k) takes 37.
he claims to use 280k of tables but the iteration calculation seems
to use only 128k. his tables and code are machine independent.
+
(code from glad@daimi.aau.dk via alt.sources or comp.sources.misc)
swedish reimplementation of Kerberos des library
- 108us per encryption (uses 34k worth of tables)
- 134us to set a new key (uses 32k of key tables to get this speed!)
+
+ - 108us per encryption (uses 34k worth of tables)
+ - 134us to set a new key (uses 32k of key tables to get this speed!)
+
the tables used seem to be machine-independent;
he seems to have included a lot of special case code
- so that, e.g., `long' loads can be used instead of 4 `char' loads
+ so that, e.g., ``long`` loads can be used instead of 4 ``char`` loads
when the machine's architecture allows it.
+
(code obtained from chalmers.se:pub/des)
crack 3.3c package from england:
+
as in crypt above, the des routine is buried in a loop. it's
also very modified for crypt. his iteration code uses 16k
of tables and appears to be slow.
+
(code obtained from aem@aber.ac.uk via alt.sources or comp.sources.misc)
-``highly optimized'' and tweaked Kerberos/Athena code (byte-order dependent):
- 165us per encryption (uses 6k worth of tables)
- 478us to set a new key (uses <1k of key tables)
+``highly optimized`` and tweaked Kerberos/Athena code (byte-order dependent):
+
+ - 165us per encryption (uses 6k worth of tables)
+ - 478us to set a new key (uses <1k of key tables)
+
so despite the comments in this code, it was possible to get
faster code AND smaller tables, as well as making the tables
machine-independent.
(code obtained from prep.ai.mit.edu)
UC Berkeley code (depends on machine-endedness):
- 226us per encryption
-10848us to set a new key
+ - 226us per encryption
+ - 10848us to set a new key
+
table sizes are unclear, but they don't look very small
(code obtained from wuarchive.wustl.edu)
motivation and history
+======================
a while ago i wanted some des routines and the routines documented on sun's
man pages either didn't exist or dumped core. i had heard of kerberos,
@@ -142,10 +177,10 @@
advantage of the regular structure of operations such as IP, E, and FP
(i.e. the author didn't sit down and think before coding),
it was excessively slow, the author had attempted to clarify the code
-by adding MORE statements to make the data movement more `consistent'
+by adding MORE statements to make the data movement more ``consistent``
instead of simplifying his implementation and cutting down on all data
movement (in particular, his use of L1, R1, L2, R2), and it was full of
-idiotic `tweaks' for particular machines which failed to deliver significant
+idiotic ``tweaks`` for particular machines which failed to deliver significant
speedups but which did obfuscate everything. so i took the test data
from his verification program and rewrote everything else.
@@ -167,12 +202,13 @@
porting notes
+=============
one thing i did not want to do was write an enormous mess
which depended on endedness and other machine quirks,
and which necessarily produced different code and different lookup tables
for different machines. see the kerberos code for an example
-of what i didn't want to do; all their endedness-specific `optimizations'
+of what i didn't want to do; all their endedness-specific ``optimizations``
obfuscate the code and in the end were slower than a simpler machine
independent approach. however, there are always some portability
considerations of some kind, and i have included some options
@@ -184,8 +220,8 @@
i assume word pointers can be freely cast to and from char pointers.
note that 99% of C programs make these assumptions.
i always use unsigned char's if the high bit could be set.
-2) the typedef `word' means a 32 bit unsigned integral type.
- if `unsigned long' is not 32 bits, change the typedef in desCore.h.
+2) the typedef ``word`` means a 32 bit unsigned integral type.
+ if ``unsigned long`` is not 32 bits, change the typedef in desCore.h.
i assume sizeof(word) == 4 EVERYWHERE.
the (worst-case) cost of my NOT doing endedness-specific optimizations
@@ -195,40 +231,46 @@
OPTIONAL performance optimizations
+==================================
-1) you should define one of `i386,' `vax,' `mc68000,' or `sparc,'
+1) you should define one of ``i386,`` ``vax,`` ``mc68000,`` or ``sparc,``
whichever one is closest to the capabilities of your machine.
see the start of desCode.h to see exactly what this selection implies.
note that if you select the wrong one, the des code will still work;
these are just performance tweaks.
-2) for those with functional `asm' keywords: you should change the
+2) for those with functional ``asm`` keywords: you should change the
ROR and ROL macros to use machine rotate instructions if you have them.
this will save 2 instructions and a temporary per use,
or about 32 to 40 instructions per en/decryption.
+
note that gcc is smart enough to translate the ROL/R macros into
machine rotates!
these optimizations are all rather persnickety, yet with them you should
be able to get performance equal to assembly-coding, except that:
+
1) with the lack of a bit rotate operator in C, rotates have to be synthesized
- from shifts. so access to `asm' will speed things up if your machine
+ from shifts. so access to ``asm`` will speed things up if your machine
has rotates, as explained above in (3) (not necessary if you use gcc).
2) if your machine has less than 12 32-bit registers i doubt your compiler will
generate good code.
- `i386' tries to configure the code for a 386 by only declaring 3 registers
+
+ ``i386`` tries to configure the code for a 386 by only declaring 3 registers
(it appears that gcc can use ebx, esi and edi to hold register variables).
however, if you like assembly coding, the 386 does have 7 32-bit registers,
- and if you use ALL of them, use `scaled by 8' address modes with displacement
+ and if you use ALL of them, use ``scaled by 8`` address modes with displacement
and other tricks, you can get reasonable routines for DesQuickCore... with
about 250 instructions apiece. For DesSmall... it will help to rearrange
des_keymap, i.e., now the sbox # is the high part of the index and
the 6 bits of data is the low part; it helps to exchange these.
+
since i have no way to conveniently test it i have not provided my
shoehorned 386 version. note that with this release of desCore, gcc is able
to put everything in registers(!), and generate about 370 instructions apiece
for the DesQuickCore... routines!
coding notes
+============
the en/decryption routines each use 6 necessary register variables,
with 4 being actively used at once during the inner iterations.
@@ -236,15 +278,18 @@
up to 8 more registers are used to hold constants in some configurations.
i assume that the use of a constant is more expensive than using a register:
+
a) additionally, i have tried to put the larger constants in registers.
registering priority was by the following:
- anything more than 12 bits (bad for RISC and CISC)
- greater than 127 in value (can't use movq or byte immediate on CISC)
- 9-127 (may not be able to use CISC shift immediate or add/sub quick),
- 1-8 were never registered, being the cheapest constants.
+
+ - anything more than 12 bits (bad for RISC and CISC)
+ - greater than 127 in value (can't use movq or byte immediate on CISC)
+ - 9-127 (may not be able to use CISC shift immediate or add/sub quick),
+ - 1-8 were never registered, being the cheapest constants.
+
b) the compiler may be too stupid to realize table and table+256 should
be assigned to different constant registers and instead repetitively
- do the arithmetic, so i assign these to explicit `m' register variables
+ do the arithmetic, so i assign these to explicit ``m`` register variables
when possible and helpful.
i assume that indexing is cheaper or equivalent to auto increment/decrement,
@@ -253,25 +298,31 @@
i assume that addresses can be cheaply formed from two registers,
or from a register and a small constant.
-for the 68000, the `two registers and small offset' form is used sparingly.
+for the 68000, the ``two registers and small offset`` form is used sparingly.
all index scaling is done explicitly - no hidden shifts by log2(sizeof).
the code is written so that even a dumb compiler
should never need more than one hidden temporary,
increasing the chance that everything will fit in the registers.
KEEP THIS MORE SUBTLE POINT IN MIND IF YOU REWRITE ANYTHING.
+
(actually, there are some code fragments now which do require two temps,
but fixing it would either break the structure of the macros or
require declaring another temporary).
special efficient data format
+==============================
-bits are manipulated in this arrangement most of the time (S7 S5 S3 S1):
+bits are manipulated in this arrangement most of the time (S7 S5 S3 S1)::
+
003130292827xxxx242322212019xxxx161514131211xxxx080706050403xxxx
+
(the x bits are still there, i'm just emphasizing where the S boxes are).
-bits are rotated left 4 when computing S6 S4 S2 S0:
+bits are rotated left 4 when computing S6 S4 S2 S0::
+
282726252423xxxx201918171615xxxx121110090807xxxx040302010031xxxx
+
the rightmost two bits are usually cleared so the lower byte can be used
as an index into an sbox mapping table. the next two x'd bits are set
to various values to access different parts of the tables.
@@ -288,7 +339,7 @@
must be long-aligned.
DesQuickInit()
- call this before using any other routine with `Quick' in its name.
+ call this before using any other routine with ``Quick`` in its name.
it generates the special 64k table these routines need.
DesQuickDone()
frees this table
@@ -298,6 +349,7 @@
which must have odd parity (or -1 is returned) and which must
not be a (semi-)weak key (or -2 is returned).
normally DesMethod() returns 0.
+
m is filled in from k so that when one of the routines below
is called with m, the routine will act like standard des
en/decryption with the key k. if you use DesMethod,
@@ -308,19 +360,26 @@
will be set to magic constants which speed up the encryption/decryption
on some machines. and yes, each byte controls
a specific sbox during a specific iteration.
+
you really shouldn't use the 768bit format directly; i should
provide a routine that converts 128 6-bit bytes (specified in
S-box mapping order or something) into the right format for you.
this would entail some byte concatenation and rotation.
Des{Small|Quick}{Fips|Core}{Encrypt|Decrypt}(d, m, s)
- performs des on the 8 bytes at s into the 8 bytes at d. (d,s: char *).
+ performs des on the 8 bytes at s into the 8 bytes at
+ ``d. (d,s: char *)``.
+
uses m as a 768bit key as explained above.
+
the Encrypt|Decrypt choice is obvious.
+
Fips|Core determines whether a completely standard FIPS initial
and final permutation is done; if not, then the data is loaded
and stored in a nonstandard bit order (FIPS w/o IP/FP).
+
Fips slows down Quick by 10%, Small by 9%.
+
Small|Quick determines whether you use the normal routine
or the crazy quick one which gobbles up 64k more of memory.
Small is 50% slower then Quick, but Quick needs 32 times as much
@@ -329,15 +388,17 @@
Getting it to compile on your machine
+=====================================
there are no machine-dependencies in the code (see porting),
-except perhaps the `now()' macro in desTest.c.
+except perhaps the ``now()`` macro in desTest.c.
ALL generated tables are machine independent.
you should edit the Makefile with the appropriate optimization flags
for your compiler (MAX optimization).
Speeding up kerberos (and/or its des library)
+=============================================
note that i have included a kerberos-compatible interface in desUtil.c
through the functions des_key_sched() and des_ecb_encrypt().
@@ -347,6 +408,7 @@
file provided with the kerberos library.
Other uses
+==========
the macros in desCode.h would be very useful for putting inline des
functions in more complicated encryption routines.
diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
index c45c6f4..f225a95 100644
--- a/Documentation/crypto/devel-algos.rst
+++ b/Documentation/crypto/devel-algos.rst
@@ -31,33 +31,23 @@
::
- int crypto_unregister_alg(struct crypto_alg *alg);
- int crypto_unregister_algs(struct crypto_alg *algs, int count);
+ void crypto_unregister_alg(struct crypto_alg *alg);
+ void crypto_unregister_algs(struct crypto_alg *algs, int count);
-Notice that both registration and unregistration functions do return a
-value, so make sure to handle errors. A return code of zero implies
-success. Any return code < 0 implies an error.
+The registration functions return 0 on success, or a negative errno
+value on failure. crypto_register_algs() succeeds only if it
+successfully registered all the given algorithms; if it fails partway
+through, then any changes are rolled back.
-The bulk registration/unregistration functions register/unregister each
-transformation in the given array of length count. They handle errors as
-follows:
-
-- crypto_register_algs() succeeds if and only if it successfully
- registers all the given transformations. If an error occurs partway
- through, then it rolls back successful registrations before returning
- the error code. Note that if a driver needs to handle registration
- errors for individual transformations, then it will need to use the
- non-bulk function crypto_register_alg() instead.
-
-- crypto_unregister_algs() tries to unregister all the given
- transformations, continuing on error. It logs errors and always
- returns zero.
+The unregistration functions always succeed, so they don't have a
+return value. Don't try to unregister algorithms that aren't
+currently registered.
Single-Block Symmetric Ciphers [CIPHER]
---------------------------------------
-Example of transformations: aes, arc4, ...
+Example of transformations: aes, serpent, ...
This section describes the simplest of all transformation
implementations, that being the CIPHER type used for symmetric ciphers.
@@ -108,7 +98,7 @@
Multi-Block Ciphers
-------------------
-Example of transformations: cbc(aes), ecb(arc4), ...
+Example of transformations: cbc(aes), chacha20, ...
This section describes the multi-block cipher transformation
implementations. The multi-block ciphers are used for transformations
@@ -128,25 +118,20 @@
overhead as the kernel crypto API needs to perform the realignment of
the data which may imply moving of data.
-Cipher Definition With struct blkcipher_alg and ablkcipher_alg
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Cipher Definition With struct skcipher_alg
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Struct blkcipher_alg defines a synchronous block cipher whereas struct
-ablkcipher_alg defines an asynchronous block cipher.
+Struct skcipher_alg defines a multi-block cipher, or more generally, a
+length-preserving symmetric cipher algorithm.
-Please refer to the single block cipher description for schematics of
-the block cipher usage.
+Scatterlist handling
+~~~~~~~~~~~~~~~~~~~~
-Specifics Of Asynchronous Multi-Block Cipher
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-There are a couple of specifics to the asynchronous interface.
-
-First of all, some of the drivers will want to use the Generic
-ScatterWalk in case the hardware needs to be fed separate chunks of the
-scatterlist which contains the plaintext and will contain the
-ciphertext. Please refer to the ScatterWalk interface offered by the
-Linux kernel scatter / gather list implementation.
+Some drivers will want to use the Generic ScatterWalk in case the
+hardware needs to be fed separate chunks of the scatterlist which
+contains the plaintext and will contain the ciphertext. Please refer
+to the ScatterWalk interface offered by the Linux kernel scatter /
+gather list implementation.
Hashing [HASH]
--------------
@@ -174,10 +159,10 @@
::
- int crypto_unregister_ahash(struct ahash_alg *alg);
+ void crypto_unregister_ahash(struct ahash_alg *alg);
- int crypto_unregister_shash(struct shash_alg *alg);
- int crypto_unregister_shashes(struct shash_alg *algs, int count);
+ void crypto_unregister_shash(struct shash_alg *alg);
+ void crypto_unregister_shashes(struct shash_alg *algs, int count);
Cipher Definition With struct shash_alg and ahash_alg
diff --git a/Documentation/crypto/index.rst b/Documentation/crypto/index.rst
index c4ff5d7..21338fa 100644
--- a/Documentation/crypto/index.rst
+++ b/Documentation/crypto/index.rst
@@ -17,9 +17,14 @@
:maxdepth: 2
intro
+ api-intro
architecture
+
+ async-tx-api
+ asymmetric-keys
devel-algos
userspace-if
crypto_engine
api
api-samples
+ descore-readme
diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
index ff86bef..b45dabb 100644
--- a/Documentation/crypto/userspace-if.rst
+++ b/Documentation/crypto/userspace-if.rst
@@ -23,7 +23,7 @@
and asynchronous invocations. The user space API call is fully
synchronous.
-[1] http://www.chronox.de/libkcapi.html
+[1] https://www.chronox.de/libkcapi.html
User Space API General Remarks
------------------------------
@@ -296,15 +296,16 @@
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
- .salg_type = "rng", /* this selects the symmetric cipher */
- .salg_name = "drbg_nopr_sha256" /* this is the cipher name */
+ .salg_type = "rng", /* this selects the random number generator */
+ .salg_name = "drbg_nopr_sha256" /* this is the RNG name */
};
Depending on the RNG type, the RNG must be seeded. The seed is provided
using the setsockopt interface to set the key. For example, the
ansi_cprng requires a seed. The DRBGs do not require a seed, but may be
-seeded.
+seeded. The seed is also known as a *Personalization String* in NIST SP 800-90A
+standard.
Using the read()/recvmsg() system calls, random numbers can be obtained.
The kernel generates at most 128 bytes in one call. If user space
@@ -314,6 +315,16 @@
system call multiple times. In this case, the returned file descriptors
have the same state.
+Following CAVP testing interfaces are enabled when kernel is built with
+CRYPTO_USER_API_RNG_CAVP option:
+
+- the concatenation of *Entropy* and *Nonce* can be provided to the RNG via
+ ALG_SET_DRBG_ENTROPY setsockopt interface. Setting the entropy requires
+ CAP_SYS_ADMIN permission.
+
+- *Additional Data* can be provided using the send()/sendmsg() system calls,
+ but only after the entropy has been set.
+
Zero-Copy Interface
-------------------
@@ -377,6 +388,9 @@
provided ciphertext is assumed to contain an authentication tag of
the given size (see section about AEAD memory layout below).
+- ALG_SET_DRBG_ENTROPY -- Setting the entropy of the random number generator.
+ This option is applicable to RNG cipher type only.
+
User space API example
----------------------
@@ -384,4 +398,4 @@
the aforementioned Netlink kernel interface. [1] also contains a test
application that invokes all libkcapi API calls.
-[1] http://www.chronox.de/libkcapi.html
+[1] https://www.chronox.de/libkcapi.html