^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) Developing Cipher Algorithms
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Registering And Unregistering Transformation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) --------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) There are three distinct types of registration functions in the Crypto
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) API. One is used to register a generic cryptographic transformation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) while the other two are specific to HASH transformations and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) COMPRESSion. We will discuss the latter two in a separate chapter, here
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) we will only look at the generic ones.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) Before discussing the register functions, the data structure to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) filled with each, struct crypto_alg, must be considered -- see below
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) for a description of this data structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) The generic registration functions can be found in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) include/linux/crypto.h and their definition can be seen below. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) former function registers a single transformation, while the latter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) works on an array of transformation descriptions. The latter is useful
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) when registering transformations in bulk, for example when a driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) implements multiple transformations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) int crypto_register_alg(struct crypto_alg *alg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) int crypto_register_algs(struct crypto_alg *algs, int count);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) The counterparts to those functions are listed below.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) void crypto_unregister_alg(struct crypto_alg *alg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) void crypto_unregister_algs(struct crypto_alg *algs, int count);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) The registration functions return 0 on success, or a negative errno
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) value on failure. crypto_register_algs() succeeds only if it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) successfully registered all the given algorithms; if it fails partway
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) through, then any changes are rolled back.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) The unregistration functions always succeed, so they don't have a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) return value. Don't try to unregister algorithms that aren't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) currently registered.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) Single-Block Symmetric Ciphers [CIPHER]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) ---------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) Example of transformations: aes, serpent, ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) This section describes the simplest of all transformation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) implementations, that being the CIPHER type used for symmetric ciphers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) The CIPHER type is used for transformations which operate on exactly one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) block at a time and there are no dependencies between blocks at all.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Registration specifics
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) ~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) The registration of [CIPHER] algorithm is specific in that struct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) crypto_alg field .cra_type is empty. The .cra_u.cipher has to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) filled in with proper callbacks to implement this transformation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) See struct cipher_alg below.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) Cipher Definition With struct cipher_alg
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) Struct cipher_alg defines a single block cipher.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) Here are schematics of how these functions are called when operated from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) other part of the kernel. Note that the .cia_setkey() call might happen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) before or after any of these schematics happen, but must not happen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) during any of these are in-flight.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) KEY ---. PLAINTEXT ---.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) v v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) .cia_setkey() -> .cia_encrypt()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) '-----> CIPHERTEXT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) Please note that a pattern where .cia_setkey() is called multiple times
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) is also valid:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) KEY1 --. PLAINTEXT1 --. KEY2 --. PLAINTEXT2 --.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) v v v v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) .cia_setkey() -> .cia_encrypt() -> .cia_setkey() -> .cia_encrypt()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) '---> CIPHERTEXT1 '---> CIPHERTEXT2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) Multi-Block Ciphers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) Example of transformations: cbc(aes), chacha20, ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) This section describes the multi-block cipher transformation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) implementations. The multi-block ciphers are used for transformations
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) which operate on scatterlists of data supplied to the transformation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) functions. They output the result into a scatterlist of data as well.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Registration Specifics
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) ~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) The registration of multi-block cipher algorithms is one of the most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) standard procedures throughout the crypto API.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) Note, if a cipher implementation requires a proper alignment of data,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) the caller should use the functions of crypto_skcipher_alignmask() to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) identify a memory alignment mask. The kernel crypto API is able to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) process requests that are unaligned. This implies, however, additional
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) overhead as the kernel crypto API needs to perform the realignment of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) the data which may imply moving of data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) Cipher Definition With struct skcipher_alg
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) Struct skcipher_alg defines a multi-block cipher, or more generally, a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) length-preserving symmetric cipher algorithm.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) Scatterlist handling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) ~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) Some drivers will want to use the Generic ScatterWalk in case the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) hardware needs to be fed separate chunks of the scatterlist which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) contains the plaintext and will contain the ciphertext. Please refer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) to the ScatterWalk interface offered by the Linux kernel scatter /
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) gather list implementation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) Hashing [HASH]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) Example of transformations: crc32, md5, sha1, sha256,...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) Registering And Unregistering The Transformation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) There are multiple ways to register a HASH transformation, depending on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) whether the transformation is synchronous [SHASH] or asynchronous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) [AHASH] and the amount of HASH transformations we are registering. You
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) can find the prototypes defined in include/crypto/internal/hash.h:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) int crypto_register_ahash(struct ahash_alg *alg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) int crypto_register_shash(struct shash_alg *alg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) int crypto_register_shashes(struct shash_alg *algs, int count);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) The respective counterparts for unregistering the HASH transformation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) are as follows:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) void crypto_unregister_ahash(struct ahash_alg *alg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) void crypto_unregister_shash(struct shash_alg *alg);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) void crypto_unregister_shashes(struct shash_alg *algs, int count);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) Cipher Definition With struct shash_alg and ahash_alg
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) Here are schematics of how these functions are called when operated from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) other part of the kernel. Note that the .setkey() call might happen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) before or after any of these schematics happen, but must not happen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) during any of these are in-flight. Please note that calling .init()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) followed immediately by .finish() is also a perfectly valid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) transformation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) I) DATA -----------.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) .init() -> .update() -> .final() ! .update() might not be called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) ^ | | at all in this scenario.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) '----' '---> HASH
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) II) DATA -----------.-----------.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) v v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) .init() -> .update() -> .finup() ! .update() may not be called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) ^ | | at all in this scenario.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) '----' '---> HASH
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) III) DATA -----------.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) .digest() ! The entire process is handled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) | by the .digest() call.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) '---------------> HASH
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) Here is a schematic of how the .export()/.import() functions are called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) when used from another part of the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) KEY--. DATA--.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) v v ! .update() may not be called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) .setkey() -> .init() -> .update() -> .export() at all in this scenario.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) ^ | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) '-----' '--> PARTIAL_HASH
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) ----------- other transformations happen here -----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) PARTIAL_HASH--. DATA1--.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) v v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) .import -> .update() -> .final() ! .update() may not be called
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) ^ | | at all in this scenario.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) '----' '--> HASH1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) PARTIAL_HASH--. DATA2-.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) v v
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) .import -> .finup()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) '---------------> HASH2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) Note that it is perfectly legal to "abandon" a request object:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) - call .init() and then (as many times) .update()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) - _not_ call any of .final(), .finup() or .export() at any point in future
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) In other words implementations should mind the resource allocation and clean-up.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) No resources related to request objects should remain allocated after a call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) to .init() or .update(), since there might be no chance to free them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) Specifics Of Asynchronous HASH Transformation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) Some of the drivers will want to use the Generic ScatterWalk in case the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) implementation needs to be fed separate chunks of the scatterlist which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) contains the input data. The buffer containing the resulting hash will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) always be properly aligned to .cra_alignmask so there is no need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) worry about this.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags