linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephan Mueller <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
	Marek Vasut <marex@denx.de>,
	Jason Cooper <cryptography@lakedaemon.net>,
	Grant Likely <grant.likely@secretlab.ca>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	linux-crypto@vger.kernel.org
Subject: [PATCH v2 06/11] crypto: Documentation - documentation of crypto_alg
Date: Sun, 02 Nov 2014 21:38:55 +0100	[thread overview]
Message-ID: <3999140.fjkrqlGA9E@tachyon.chronox.de> (raw)
In-Reply-To: <6375771.bx7QqLJLuR@tachyon.chronox.de>

The data structure of struct crypto_alg is documented for all parameters
that can be set by a developer of a transformation. All parameters that
are internal to the crypto API are marked as such.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
CC: Marek Vasut <marex@denx.de>
---
 include/linux/crypto.h | 157 ++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 137 insertions(+), 20 deletions(-)

diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index d45e949..e1a84fd 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -277,22 +277,104 @@ struct rng_alg {
 #define cra_compress	cra_u.compress
 #define cra_rng		cra_u.rng
 
+/**
+ * The struct crypto_alg describes a generic Crypto API algorithm and is common
+ * for all of the transformations. The flags marked as internal shall not
+ * be set or modified by a transformation implementation.
+ */
 struct crypto_alg {
-	struct list_head cra_list;
-	struct list_head cra_users;
-
-	u32 cra_flags;
-	unsigned int cra_blocksize;
+	struct list_head cra_list; /** <Internal to the Crypto API */
+	struct list_head cra_users; /** <Internal to the Crypto API */
+
+	u32 cra_flags; /** <Flags describing this transformation. See
+			* include/linux/crypto.h CRYPTO_ALG_* flags for the
+			* flags which go in here. Those are used for
+			* fine-tuning the description of the transformation
+			* algorithm.
+			*/
+	unsigned int cra_blocksize; /** <Minimum block size of this
+				     * transformation. The size in bytes of the
+				     * smallest possible unit which
+				     * can be transformed with this algorithm.
+				     * The users must respect this value.
+				     * In case of HASH transformation, it is
+				     * possible for a smaller block than
+				     * .cra_blocksize to be passed to the
+				     * crypto API for transformation, in case
+				     * of any other transformation type, an
+				     * error will be returned upon any attempt
+				     * to transform smaller than .cra_blocksize
+				     * chunks.
+				     */
 	unsigned int cra_ctxsize;
-	unsigned int cra_alignmask;
-
-	int cra_priority;
-	atomic_t cra_refcnt;
-
-	char cra_name[CRYPTO_MAX_ALG_NAME];
-	char cra_driver_name[CRYPTO_MAX_ALG_NAME];
-
-	const struct crypto_type *cra_type;
+	unsigned int cra_alignmask; /** <Alignment mask for the input and
+				     * output data buffer. The data buffer
+				     * containing the input data for the
+				     * algorithm must be aligned to this
+				     * alignment mask. The data buffer for the
+				     * output data must be aligned to this
+				     * alignment mask. Note that the Crypto API
+				     * will do the re-alignment in software, but
+				     * only under special conditions and there
+				     * is a performance hit. The re-alignment
+				     * happens at these occasions for different
+				     * .cra_u types:
+				     * cipher: For both input data and output
+				     *         data buffer
+				     * ahash:  For output hash destination buf
+				     * shash:  For output hash destination buf
+				     * This is needed on hardware which is
+				     * flawed by design and cannot pick data
+				     * from arbitrary addresses.
+				     */
+
+	int cra_priority; /** <Priority of this transformation implementation.
+			   * In case multiple transformations with same
+			   *.cra_name are available to the Crypto API, the
+			   * kernel will use the one with highest .cra_priority
+			   */
+	atomic_t cra_refcnt; /** <Internal to the Crypto API */
+
+	char cra_name[CRYPTO_MAX_ALG_NAME]; /** <Generic name (usable by
+					     * multiple implementations) of the
+					     * transformation algorithm. This is
+					     * the name of the transformation
+					     * itself. This field is used by the
+					     * kernel when looking up the
+					     * providers of particular
+					     * transformation.
+					     */
+	char cra_driver_name[CRYPTO_MAX_ALG_NAME]; /** <Unique name of the
+						    * transformation provider.
+						    * This is the name of the
+						    * provider of the
+						    * transformation. This can
+						    * be any arbitrary value,
+						    * but in the usual case,
+						    * this contains the name of
+						    * the chip or provider and
+						    * the name of the
+						    * transformation algorithm.
+						    */
+
+	const struct crypto_type *cra_type; /** <Type of the cryptographic
+					     * transformation. This is a pointer
+					     * to struct crypto_type, which
+					     * implements callbacks common for
+					     * all trasnformation types. There
+					     * are multiple options:
+					     *  crypto_blkcipher_type
+					     *  crypto_ablkcipher_type
+					     *  crypto_ahash_type
+					     *  crypto_aead_type
+					     *  crypto_rng_type
+					     * This field might be empty. In
+					     * that case, there are no common
+					     * callbacks. This is the case for:
+					     *  cipher
+					     *  compress
+					     *  shash
+					     */
 
 	union {
 		struct ablkcipher_alg ablkcipher;
@@ -301,13 +383,48 @@ struct crypto_alg {
 		struct cipher_alg cipher;
 		struct compress_alg compress;
 		struct rng_alg rng;
-	} cra_u;
-
-	int (*cra_init)(struct crypto_tfm *tfm);
-	void (*cra_exit)(struct crypto_tfm *tfm);
-	void (*cra_destroy)(struct crypto_alg *alg);
+	} cra_u; /** <Callbacks implementing the transformation. This is a union
+		  * of multiple structures. Depending on the type of
+		  * transformation selected by .cra_type and .cra_flags above,
+		  * the associated structure must be filled with callbacks.
+		  * This field might be empty. This is the case for:
+		  *  ahash
+		  *  shash
+		  */
+
+	int (*cra_init)(struct crypto_tfm *tfm); /** <Initialize the
+						  * cryptographic transformation
+						  * object. This function is
+						  * used to initialize the
+						  * cryptographic transformation
+						  * object. This function is
+						  * called only once at the
+						  * instantiation time, right
+						  * after the transformation
+						  * context was allocated.
+						  * In case the cryptographic
+						  * hardware has some special
+						  * requirements which need to
+						  * be handled by software, this
+						  * function shall check for the
+						  * precise requirement of the
+						  * transformation and put any
+						  * software fallbacks in place.
+						  */
+	void (*cra_exit)(struct crypto_tfm *tfm); /** <Deinitialize the
+						   * cryptographic
+						   * transformation object.
+						   * This is a counterpart to
+						   * .cra_init(), used to remove
+						   * various changes set in
+						   * .cra_init().
+						   */
+	void (*cra_destroy)(struct crypto_alg *alg); /** <Internal to the Crypto
+						      * API */
 	
-	struct module *cra_module;
+	struct module *cra_module; /** <Owner of this transformation
+				    * implementation. Set to THIS_MODULE
+				    */
 };
 
 /*
-- 
2.1.0

  parent reply	other threads:[~2014-11-02 20:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02 20:34 [PATCH v2 00/11] crypto: Documentation of kernel crypto API Stephan Mueller
2014-11-02 20:35 ` [PATCH v2 01/11] crypto: Documentation - crypto API high level spec Stephan Mueller
2014-11-03 13:34   ` Jonathan Corbet
2014-11-03 14:18     ` Stephan Mueller
2014-11-03 14:43       ` Herbert Xu
2014-11-03 14:49       ` Herbert Xu
2014-11-03 15:53         ` Tom Lendacky
2014-11-03 16:44       ` Jonathan Corbet
2014-11-09  2:54       ` Jason Cooper
2014-11-05 22:21   ` Joy M. Latten
2014-11-06  2:15   ` Tadeusz Struk
2014-11-10  1:41     ` Stephan Mueller
2014-11-02 20:36 ` [PATCH v2 02/11] crypto: Documentation - userspace interface spec Stephan Mueller
2014-11-05 23:20   ` Joy M. Latten
2014-11-02 20:36 ` [PATCH v2 03/11] crypto: Documentation - RNG API documentation Stephan Mueller
2014-11-05 23:33   ` Joy M. Latten
2014-11-02 20:37 ` [PATCH v2 04/11] crypto: Documentation - AHASH " Stephan Mueller
2014-11-02 20:38 ` [PATCH v2 05/11] crypto: Documentation - SHASH " Stephan Mueller
2014-11-06 22:43   ` Joy M. Latten
2014-11-02 20:38 ` Stephan Mueller [this message]
2014-11-02 20:39 ` [PATCH v2 07/11] crypto: Documentation - ABLKCIPHER " Stephan Mueller
2014-11-02 20:40 ` [PATCH v2 08/11] crypto: Documentation - AEAD " Stephan Mueller
2014-11-02 20:40 ` [PATCH v2 09/11] crypto: Documentation - BLKCIPHER " Stephan Mueller
2014-11-02 20:41 ` [PATCH v2 10/11] crypto: Documentation - CIPHER " Stephan Mueller
2014-11-02 20:42 ` [PATCH v2 11/11] crypto: Documentation - HASH " Stephan Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3999140.fjkrqlGA9E@tachyon.chronox.de \
    --to=smueller@chronox.de \
    --cc=cryptography@lakedaemon.net \
    --cc=davem@davemloft.net \
    --cc=geert@linux-m68k.org \
    --cc=grant.likely@secretlab.ca \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).