forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git…
…/herbert/crypto-2.6 Pull crypto updates from Herbert Xu: "Here is the crypto update for 5.3: API: - Test shash interface directly in testmgr - cra_driver_name is now mandatory Algorithms: - Replace arc4 crypto_cipher with library helper - Implement 5 way interleave for ECB, CBC and CTR on arm64 - Add xxhash - Add continuous self-test on noise source to drbg - Update jitter RNG Drivers: - Add support for SHA204A random number generator - Add support for 7211 in iproc-rng200 - Fix fuzz test failures in inside-secure - Fix fuzz test failures in talitos - Fix fuzz test failures in qat" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (143 commits) crypto: stm32/hash - remove interruptible condition for dma crypto: stm32/hash - Fix hmac issue more than 256 bytes crypto: stm32/crc32 - rename driver file crypto: amcc - remove memset after dma_alloc_coherent crypto: ccp - Switch to SPDX license identifiers crypto: ccp - Validate the the error value used to index error messages crypto: doc - Fix formatting of new crypto engine content crypto: doc - Add parameter documentation crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR crypto: arm64/aes-ce - add 5 way interleave routines crypto: talitos - drop icv_ool crypto: talitos - fix hash on SEC1. crypto: talitos - move struct talitos_edesc into talitos.h lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE crypto/NX: Set receive window credits to max number of CRBs in RxFIFO crypto: asymmetric_keys - select CRYPTO_HASH where needed crypto: serpent - mark __serpent_setkey_sbox noinline crypto: testmgr - dynamically allocate crypto_shash crypto: testmgr - dynamically allocate testvec_config crypto: talitos - eliminate unneeded 'done' functions at build time ...
- Loading branch information
Showing
168 changed files
with
4,527 additions
and
3,798 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,50 +1,85 @@ | ||
============= | ||
CRYPTO ENGINE | ||
.. SPDX-License-Identifier: GPL-2.0 | ||
Crypto Engine | ||
============= | ||
|
||
Overview | ||
-------- | ||
The crypto engine API (CE), is a crypto queue manager. | ||
The crypto engine (CE) API is a crypto queue manager. | ||
|
||
Requirement | ||
----------- | ||
You have to put at start of your tfm_ctx the struct crypto_engine_ctx:: | ||
You must put, at the start of your transform context your_tfm_ctx, the structure | ||
crypto_engine: | ||
|
||
:: | ||
|
||
struct your_tfm_ctx { | ||
struct crypto_engine_ctx enginectx; | ||
... | ||
}; | ||
struct your_tfm_ctx { | ||
struct crypto_engine engine; | ||
... | ||
}; | ||
|
||
Why: Since CE manage only crypto_async_request, it cannot know the underlying | ||
request_type and so have access only on the TFM. | ||
So using container_of for accessing __ctx is impossible. | ||
Furthermore, the crypto engine cannot know the "struct your_tfm_ctx", | ||
so it must assume that crypto_engine_ctx is at start of it. | ||
The crypto engine only manages asynchronous requests in the form of | ||
crypto_async_request. It cannot know the underlying request type and thus only | ||
has access to the transform structure. It is not possible to access the context | ||
using container_of. In addition, the engine knows nothing about your | ||
structure "``struct your_tfm_ctx``". The engine assumes (requires) the placement | ||
of the known member ``struct crypto_engine`` at the beginning. | ||
|
||
Order of operations | ||
------------------- | ||
You have to obtain a struct crypto_engine via crypto_engine_alloc_init(). | ||
And start it via crypto_engine_start(). | ||
|
||
Before transferring any request, you have to fill the enginectx. | ||
- prepare_request: (taking a function pointer) If you need to do some processing before doing the request | ||
- unprepare_request: (taking a function pointer) Undoing what's done in prepare_request | ||
- do_one_request: (taking a function pointer) Do encryption for current request | ||
|
||
Note: that those three functions get the crypto_async_request associated with the received request. | ||
So your need to get the original request via container_of(areq, struct yourrequesttype_request, base); | ||
|
||
When your driver receive a crypto_request, you have to transfer it to | ||
the cryptoengine via one of: | ||
- crypto_transfer_ablkcipher_request_to_engine() | ||
- crypto_transfer_aead_request_to_engine() | ||
- crypto_transfer_akcipher_request_to_engine() | ||
- crypto_transfer_hash_request_to_engine() | ||
- crypto_transfer_skcipher_request_to_engine() | ||
|
||
At the end of the request process, a call to one of the following function is needed: | ||
- crypto_finalize_ablkcipher_request | ||
- crypto_finalize_aead_request | ||
- crypto_finalize_akcipher_request | ||
- crypto_finalize_hash_request | ||
- crypto_finalize_skcipher_request | ||
You are required to obtain a struct crypto_engine via ``crypto_engine_alloc_init()``. | ||
Start it via ``crypto_engine_start()``. When finished with your work, shut down the | ||
engine using ``crypto_engine_stop()`` and destroy the engine with | ||
``crypto_engine_exit()``. | ||
|
||
Before transferring any request, you have to fill the context enginectx by | ||
providing functions for the following: | ||
|
||
* ``prepare_crypt_hardware``: Called once before any prepare functions are | ||
called. | ||
|
||
* ``unprepare_crypt_hardware``: Called once after all unprepare functions have | ||
been called. | ||
|
||
* ``prepare_cipher_request``/``prepare_hash_request``: Called before each | ||
corresponding request is performed. If some processing or other preparatory | ||
work is required, do it here. | ||
|
||
* ``unprepare_cipher_request``/``unprepare_hash_request``: Called after each | ||
request is handled. Clean up / undo what was done in the prepare function. | ||
|
||
* ``cipher_one_request``/``hash_one_request``: Handle the current request by | ||
performing the operation. | ||
|
||
Note that these functions access the crypto_async_request structure | ||
associated with the received request. You are able to retrieve the original | ||
request by using: | ||
|
||
:: | ||
|
||
container_of(areq, struct yourrequesttype_request, base); | ||
|
||
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() | ||
|
||
* crypto_transfer_hash_request_to_engine() | ||
|
||
* crypto_transfer_skcipher_request_to_engine() | ||
|
||
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() | ||
|
||
* crypto_finalize_hash_request() | ||
|
||
* crypto_finalize_skcipher_request() |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4257,6 +4257,7 @@ F: crypto/ | |
F: drivers/crypto/ | ||
F: include/crypto/ | ||
F: include/linux/crypto* | ||
F: lib/crypto/ | ||
|
||
CRYPTOGRAPHIC RANDOM NUMBER GENERATOR | ||
M: Neil Horman <[email protected]> | ||
|
Oops, something went wrong.