[GIT PULL] LLVMLinux patches for v3.18
These patches remove the use of VLAIS using a new SHASH_DESC_ON_STACK macro. Some of the previously accepted VLAIS removal patches haven't used this macro. I will push new patches to consistently use this macro in all those older cases for 3.19 The following changes since commit 2d65a9f48fcdf7866aab6457bc707ca233e0c791: Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux (2014-10-14 09:39:08 +0200) are available in the git repository at: git://git.linuxfoundation.org/llvmlinux/kernel.git tags/llvmlinux-for-v3.18 for you to fetch changes up to 4c5c30249452aaebf258751ea4222eba3dd3da4c: crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c (2014-10-14 10:51:24 +0200) LLVMLinux patches for v3.18 Behan Webster (6): crypto: LLVMLinux: Add macro to remove use of VLAIS in crypto code crypto: LLVMLinux: Remove VLAIS from crypto/mv_cesa.c crypto: LLVMLinux: Remove VLAIS from crypto/n2_core.c crypto: LLVMLinux: Remove VLAIS from crypto/omap_sham.c crypto: LLVMLinux: Remove VLAIS from crypto/.../qat_algs.c security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c Jan-Simon Möller (5): crypto: LLVMLinux: Remove VLAIS from crypto/ccp/ccp-crypto-sha.c crypto, dm: LLVMLinux: Remove VLAIS usage from dm-crypt crypto: LLVMLinux: Remove VLAIS usage from crypto/hmac.c crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.c crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c Vinícius Tinti (1): btrfs: LLVMLinux: Remove VLAIS crypto/hmac.c| 25 - crypto/testmgr.c | 14 -- drivers/crypto/ccp/ccp-crypto-sha.c | 13 - drivers/crypto/mv_cesa.c | 41 drivers/crypto/n2_core.c | 11 +++- drivers/crypto/omap-sham.c | 28 --- drivers/crypto/qat/qat_common/qat_algs.c | 31 ++--- drivers/md/dm-crypt.c| 34 ++- fs/btrfs/hash.c | 16 +-- include/crypto/hash.h| 5 lib/libcrc32c.c | 16 +-- security/integrity/ima/ima_crypto.c | 47 +--- 12 files changed, 122 insertions(+), 159 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] crypto: caam - add support for gcm(aes)
Add support for AES working in Galois Counter Mode.
There is a limitation related to IV size, similar to the one present in
SW implementation (crypto/gcm.c):
The only IV size allowed is 12 bytes. It will be padded by HW to the right
with 0x_0001 (up to 16 bytes - AES block size), according to the GCM
specification.
Signed-off-by: Tudor Ambarus tudor.amba...@freescale.com
Signed-off-by: Horia Geanta horia.gea...@freescale.com
---
drivers/crypto/caam/caamalg.c | 331 --
1 file changed, 321 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index a80ea85..3486a69 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -74,6 +74,10 @@
#define DESC_AEAD_NULL_ENC_LEN (DESC_AEAD_NULL_BASE + 14 * CAAM_CMD_SZ)
#define DESC_AEAD_NULL_DEC_LEN (DESC_AEAD_NULL_BASE + 17 * CAAM_CMD_SZ)
+#define DESC_GCM_BASE (3 * CAAM_CMD_SZ)
+#define DESC_GCM_ENC_LEN (DESC_GCM_BASE + 23 * CAAM_CMD_SZ)
+#define DESC_GCM_DEC_LEN (DESC_GCM_BASE + 19 * CAAM_CMD_SZ)
+
#define DESC_ABLKCIPHER_BASE (3 * CAAM_CMD_SZ)
#define DESC_ABLKCIPHER_ENC_LEN(DESC_ABLKCIPHER_BASE + \
20 * CAAM_CMD_SZ)
@@ -630,6 +634,236 @@ static int aead_setauthsize(struct crypto_aead *authenc,
return 0;
}
+static int gcm_set_sh_desc(struct crypto_aead *aead)
+{
+ struct aead_tfm *tfm = aead-base.crt_aead;
+ struct caam_ctx *ctx = crypto_aead_ctx(aead);
+ struct device *jrdev = ctx-jrdev;
+ bool keys_fit_inline = false;
+ u32 *key_jump_cmd, *zero_payload_jump_cmd,
+ *zero_assoc_jump_cmd1, *zero_assoc_jump_cmd2;
+ u32 *desc;
+
+ if (!ctx-enckeylen || !ctx-authsize)
+ return 0;
+
+ /*
+* AES GCM encrypt shared descriptor
+* Job Descriptor and Shared Descriptor
+* must fit into the 64-word Descriptor h/w Buffer
+*/
+ if (DESC_GCM_ENC_LEN + DESC_JOB_IO_LEN +
+ ctx-enckeylen = CAAM_DESC_BYTES_MAX)
+ keys_fit_inline = true;
+
+ desc = ctx-sh_desc_enc;
+
+ init_sh_desc(desc, HDR_SHARE_SERIAL);
+
+ /* skip key loading if they are loaded due to sharing */
+ key_jump_cmd = append_jump(desc, JUMP_JSL | JUMP_TEST_ALL |
+ JUMP_COND_SHRD | JUMP_COND_SELF);
+ if (keys_fit_inline)
+ append_key_as_imm(desc, (void *)ctx-key, ctx-enckeylen,
+ ctx-enckeylen, CLASS_1 | KEY_DEST_CLASS_REG);
+ else
+ append_key(desc, ctx-key_dma, ctx-enckeylen,
+ CLASS_1 | KEY_DEST_CLASS_REG);
+ set_jump_tgt_here(desc, key_jump_cmd);
+
+ /* class 1 operation */
+ append_operation(desc, ctx-class1_alg_type |
+OP_ALG_AS_INITFINAL | OP_ALG_ENCRYPT);
+
+ /* cryptlen = seqoutlen - authsize */
+ append_math_sub_imm_u32(desc, REG3, SEQOUTLEN, IMM, ctx-authsize);
+
+ /* assoclen + cryptlen = seqinlen - ivsize */
+ append_math_sub_imm_u32(desc, REG2, SEQINLEN, IMM, tfm-ivsize);
+
+ /* assoclen = (assoclen + cryptlen) - cryptlen */
+ append_math_sub(desc, REG1, REG2, REG3, CAAM_CMD_SZ);
+
+ /* if cryptlen is ZERO jump to zero-payload commands */
+ append_math_add(desc, VARSEQOUTLEN, ZERO, REG3, CAAM_CMD_SZ);
+ zero_payload_jump_cmd = append_jump(desc, JUMP_TEST_ALL |
+ JUMP_COND_MATH_Z);
+ /* read IV */
+ append_seq_fifo_load(desc, tfm-ivsize, FIFOLD_CLASS_CLASS1 |
+FIFOLD_TYPE_IV | FIFOLD_TYPE_FLUSH1);
+
+ /* if assoclen is ZERO, skip reading the assoc data */
+ append_math_add(desc, VARSEQINLEN, ZERO, REG1, CAAM_CMD_SZ);
+ zero_assoc_jump_cmd1 = append_jump(desc, JUMP_TEST_ALL |
+ JUMP_COND_MATH_Z);
+
+ /* read assoc data */
+ append_seq_fifo_load(desc, 0, FIFOLD_CLASS_CLASS1 | FIFOLDST_VLF |
+FIFOLD_TYPE_AAD | FIFOLD_TYPE_FLUSH1);
+ set_jump_tgt_here(desc, zero_assoc_jump_cmd1);
+
+ append_math_add(desc, VARSEQINLEN, ZERO, REG3, CAAM_CMD_SZ);
+
+ /* write encrypted data */
+ append_seq_fifo_store(desc, 0, FIFOST_TYPE_MESSAGE_DATA | FIFOLDST_VLF);
+
+ /* read payload data */
+ append_seq_fifo_load(desc, 0, FIFOLD_CLASS_CLASS1 | FIFOLDST_VLF |
+FIFOLD_TYPE_MSG | FIFOLD_TYPE_LAST1);
+
+ /* jump the zero-payload commands */
+ append_jump(desc, JUMP_TEST_ALL | 7);
+
+ /* zero-payload commands */
+ set_jump_tgt_here(desc, zero_payload_jump_cmd);
+
+ /* if assoclen is ZERO, jump to IV reading - is the only input data */
+ append_math_add(desc, VARSEQINLEN, ZERO, REG1, CAAM_CMD_SZ);
+
Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration
On 10/13/2014 09:24 PM, Tadeusz Struk wrote:
snip
- node = adf_get_dev_node_id(pdev);
- accel_dev = kzalloc_node(sizeof(*accel_dev), GFP_KERNEL, node);
+ if (num_possible_nodes() 1 dev_to_node(pdev-dev) 0) {
+ /* If the accelerator is connected to a node with no memory
+ * there is no point in using the accelerator since the remote
+ * memory transaction will be very slow. */
+ dev_err(pdev-dev, Invalid NUMA configuration.\n);
This is a lot better. Thank you for taking my comments into account here.
Let's say I have a non-functional qat device and I see the above message in
the boot log. The log doesn't say what to do ... so perhaps change it to
dev_err(pdev-dev, FW_BUG numa node is set to %d. This can be
overridden by
using the numa_node module parameter.,
dev_to_node(pdev-dev));
and add a numa_node module parameter to let the user set that at module load
time in case their FW is broken? I've found that sysadmins are knowledgeable
about these types of things these days and are more than capable of looking
at sysfs and numactl to determine where a device is.
P.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration
On 10/14/2014 03:53 AM, Prarit Bhargava wrote:
-node = adf_get_dev_node_id(pdev);
-accel_dev = kzalloc_node(sizeof(*accel_dev), GFP_KERNEL, node);
+if (num_possible_nodes() 1 dev_to_node(pdev-dev) 0) {
+/* If the accelerator is connected to a node with no memory
+ * there is no point in using the accelerator since the remote
+ * memory transaction will be very slow. */
+dev_err(pdev-dev, Invalid NUMA configuration.\n);
This is a lot better. Thank you for taking my comments into account here.
Thanks for taking the time to review my patch and providing your comments.
Let's say I have a non-functional qat device and I see the above message in
the boot log. The log doesn't say what to do ... so perhaps change it to
dev_err(pdev-dev, FW_BUG numa node is set to %d. This can be
overridden by
using the numa_node module parameter.,
dev_to_node(pdev-dev));
and add a numa_node module parameter to let the user set that at module load
time in case their FW is broken? I've found that sysadmins are knowledgeable
about these types of things these days and are more than capable of looking
at sysfs and numactl to determine where a device is.
But then what if there are two devices and each belongs to different
node. In this case we would fix one and break the other. I think if the
FW is broken then using on core encryption will be safer. If a sysadmins
is really knowledgeable, then she or he can change the code to customize
it for a given platform and rebuild the module.
Other than that as far as I know module parameters are not encouraged.
T
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration
On 10/14/2014 10:50 AM, Tadeusz Struk wrote:
On 10/14/2014 03:53 AM, Prarit Bhargava wrote:
- node = adf_get_dev_node_id(pdev);
- accel_dev = kzalloc_node(sizeof(*accel_dev), GFP_KERNEL, node);
+ if (num_possible_nodes() 1 dev_to_node(pdev-dev) 0) {
+ /* If the accelerator is connected to a node with no memory
+* there is no point in using the accelerator since the remote
+* memory transaction will be very slow. */
+ dev_err(pdev-dev, Invalid NUMA configuration.\n);
This is a lot better. Thank you for taking my comments into account here.
Thanks for taking the time to review my patch and providing your comments.
Let's say I have a non-functional qat device and I see the above message in
the boot log. The log doesn't say what to do ... so perhaps change it to
dev_err(pdev-dev, FW_BUG numa node is set to %d. This can be
overridden by
using the numa_node module parameter.,
dev_to_node(pdev-dev));
and add a numa_node module parameter to let the user set that at module load
time in case their FW is broken? I've found that sysadmins are knowledgeable
about these types of things these days and are more than capable of looking
at sysfs and numactl to determine where a device is.
But then what if there are two devices and each belongs to different
node. In this case we would fix one and break the other. I think if the
Oh, that's a really good point. But can you at least change the message to do a
FW_BUG and dump the node information? That would be useful for debugging.
P.
FW is broken then using on core encryption will be safer. If a sysadmins
is really knowledgeable, then she or he can change the code to customize
it for a given platform and rebuild the module.
Other than that as far as I know module parameters are not encouraged.
T
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration
On 10/14/2014 08:41 AM, Prarit Bhargava wrote: Oh, that's a really good point. But can you at least change the message to do a FW_BUG and dump the node information? That would be useful for debugging. But this not always will be a FW_BUG. If a user will not populate one of the nodes with memory this will happen as well. I could see this to be the main reason of this message to be printed. In this case num_possible_nodes() will be e.g. 2 and dev_to_node(pdev-dev) will be -1 so I don't really know what will be a useful info to print so we don't confuse the user. T -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration
On 10/14/2014 01:18 PM, Tadeusz Struk wrote: On 10/14/2014 08:41 AM, Prarit Bhargava wrote: Oh, that's a really good point. But can you at least change the message to do a FW_BUG and dump the node information? That would be useful for debugging. But this not always will be a FW_BUG. If a user will not populate one of the nodes with memory this will happen as well. Hmmm ... let's maybe think about this. I wonder if there is some mechanism with which we can determine that? Larry Woodman -- is there any mm related call that we can make to determine if a node is memory-less? I could see this to be the main reason of this message to be printed. In this case num_possible_nodes() will be e.g. 2 and dev_to_node(pdev-dev) will be -1 so I don't really know what will be a useful info to print so we don't confuse the user. If you see -1, it means No node was assigned ... so -1 in a debug message is okay IMO. P. T -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] crypto: qat - Enforce valid numa configuration
On 10/14/2014 01:27 PM, Prarit Bhargava wrote: On 10/14/2014 01:18 PM, Tadeusz Struk wrote: On 10/14/2014 08:41 AM, Prarit Bhargava wrote: Oh, that's a really good point. But can you at least change the message to do a FW_BUG and dump the node information? That would be useful for debugging. But this not always will be a FW_BUG. If a user will not populate one of the nodes with memory this will happen as well. Hmmm ... let's maybe think about this. I wonder if there is some mechanism with which we can determine that? Larry Woodman -- is there any mm related call that we can make to determine if a node is memory-less? I could see this to be the main reason of this message to be printed. In this case num_possible_nodes() will be e.g. 2 and dev_to_node(pdev-dev) will be -1 so I don't really know what will be a useful info to print so we don't confuse the user. If you see -1, it means No node was assigned ... so -1 in a debug message is okay IMO. Never mind -- I'm not thinking straight after a long weekend :) This is all okay. The message above will only print iff node 0, ie) -1. So I'll ack shortly. P. P. T -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kernel crypto API interface specification
The update adds a complete interface documentation of the kernel crypto API. All cipher types supported by the kernel crypto API are documented. In addition, kernel and user space example code is provided. The sample code covers synchronous and asynchronous cipher operation, random number generation and performing hashing as well as encryption and decryption in user space. Signed-off-by: Stephan Mueller smuel...@chronox.de --- Documentation/crypto/crypto-API-spec.txt | 2110 ++ 1 file changed, 2110 insertions(+) create mode 100644 Documentation/crypto/crypto-API-spec.txt diff --git a/Documentation/crypto/crypto-API-spec.txt b/Documentation/crypto/crypto-API-spec.txt new file mode 100644 index 000..027fd4f --- /dev/null +++ b/Documentation/crypto/crypto-API-spec.txt @@ -0,0 +1,2110 @@ +Kernel Crypto API Interface Specification += + +The kernel crypto API offers a rich set of ciphers and methods to invoke these +ciphers. This document contains a description of the API and provides example +code. + +To understand and properly use the kernel crypto API a brief explanation of the +structure is given. Based on the architecture, the API can be separated into +different components. Following the architecture specification the various +components forming the kernel crypto API are described. + +The kernel crypto API refers to all algorithms as transforms. Therefore, a +cipher handle variable usually has the name tfm. Besides cryptographic +operations, the kernel crypto API also knows compression transforms and handles +them the same way as ciphers. + +The kernel crypto API serves the following entity types: + + * users requesting cryptographic services + + * data transformation implementations (typically ciphers) that + can be called by users + +This specification is mainly intended for normal users that need cryptographic +support. It lists all API calls relevant for these users. This API +specification, however, does not list all API calls available to data +transformation implementations ((i.e. implementations of ciphers and other +transformations (such as CRC or even compression algorithms) that can register +with the kernel crypto API). + +Kernel Crypto API Architecture +== + +Cipher types + + +The kernel crypto API provides different API calls for the following cipher +types: + + * Symmetric ciphers + + * AEAD ciphers + + * Message digest, including keyed message digest + + * Random number generation + + * User space interface + +Ciphers and Templates +- + +The kernel crypto API provides implementations of raw ciphers. In addition, the +kernel crypto API provides numerous templates that can be used in conjunction +with the raw ciphers. Templates include all types of block chaining mode, the +HMAC mechanism, etc. + +Raw ciphers can either be directly used by a caller or invoked together with a +template. A raw cipher may even be called with multiple templates. However, +templates cannot be used without a raw cipher. + +Synchronous and asynchronous operation +-- + +The kernel crypto API provides synchronous and asynchronous API calls. + +When using a synchronous API call, the caller invokes a cipher operation which +is performed synchronously by the kernel crypto API. That means, the caller +waits until the cipher operation completes. Therefore, the kernel crypto +API calls work like regular function calls. For synchronous operations, the set +of API calls is small and similar to any other crypto library. + +Asynchronous operation is provided by the kernel crypto API which implies that +the invocation of a cipher operation will complete almost instantly. That +invocation triggers the cipher operation but it does not signal its completion. +Before invoking a cipher operation, the caller must provide a callback function +the kernel crypto API can invoke to signal the completion of the cipher +operation. Furthermore, the caller must ensure it can handle such asynchronous +events by applying appropriate locking around its data. The kernel crypto API +does not perform any special serialization operation to protect the caller's +data integrity. + +Kernel crypto API cipher references and priority + + +A cipher is referenced by the caller with a string. That string has the +following semantics: + + template(raw cipher) + +where template and raw cipher is the aforementioned template and raw cipher, +respectively. If applicable, additional templates may enclose other templates, +such as + + template1(template2(raw cipher))) + +The kernel crypto API may provide multiple implementations of a template or a +raw cipher. For example, AES on newer x86_64 hardware has the following +implementations: AES-NI, assembler implementation, or straight C.
[PATCH] crypto: drbg - use crypto_inc
The DRBG internal buffer addition function is replaced with crypto_inc when
a buffer is to be incremented by one.
The function drbg_add_buf is moved to the CONFIG_CRYPTO_DRBG_HASH ifdef
area as it is now only needed for the Hash DRBG.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/drbg.c | 79 ---
1 file changed, 38 insertions(+), 41 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 54cfd48..8c0a742 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -283,38 +283,6 @@ static inline void drbg_cpu_to_be32(__u32 val, unsigned
char *buf)
conversion-conv = cpu_to_be32(val);
}
-
-/*
- * Increment buffer
- *
- * @dst buffer to increment
- * @add value to add
- */
-static inline void drbg_add_buf(unsigned char *dst, size_t dstlen,
- const unsigned char *add, size_t addlen)
-{
- /* implied: dstlen addlen */
- unsigned char *dstptr;
- const unsigned char *addptr;
- unsigned int remainder = 0;
- size_t len = addlen;
-
- dstptr = dst + (dstlen-1);
- addptr = add + (addlen-1);
- while (len) {
- remainder += *dstptr + *addptr;
- *dstptr = remainder 0xff;
- remainder = 8;
- len--; dstptr--; addptr--;
- }
- len = dstlen - addlen;
- while (len remainder 0) {
- remainder = *dstptr + 1;
- *dstptr = remainder 0xff;
- remainder = 8;
- len--; dstptr--;
- }
-}
#endif /* defined(CONFIG_CRYPTO_DRBG_HASH) || defined(CONFIG_CRYPTO_DRBG_CTR)
*/
/**
@@ -554,7 +522,6 @@ static int drbg_ctr_update(struct drbg_state *drbg, struct
list_head *seed,
unsigned char *temp_p, *df_data_p; /* pointer to iterate over buffers */
unsigned int len = 0;
struct drbg_string cipherin;
- unsigned char prefix = DRBG_PREFIX1;
memset(temp, 0, drbg_statelen(drbg) + drbg_blocklen(drbg));
if (3 reseed)
@@ -574,7 +541,7 @@ static int drbg_ctr_update(struct drbg_state *drbg, struct
list_head *seed,
*/
while (len (drbg_statelen(drbg))) {
/* 10.2.1.2 step 2.1 */
- drbg_add_buf(drbg-V, drbg_blocklen(drbg), prefix, 1);
+ crypto_inc(drbg-V, drbg_blocklen(drbg));
/*
* 10.2.1.2 step 2.2 */
ret = drbg_kcapi_sym(drbg, drbg-C, temp + len, cipherin);
@@ -617,7 +584,6 @@ static int drbg_ctr_generate(struct drbg_state *drbg,
int len = 0;
int ret = 0;
struct drbg_string data;
- unsigned char prefix = DRBG_PREFIX1;
memset(drbg-scratchpad, 0, drbg_blocklen(drbg));
@@ -629,7 +595,7 @@ static int drbg_ctr_generate(struct drbg_state *drbg,
}
/* 10.2.1.5.2 step 4.1 */
- drbg_add_buf(drbg-V, drbg_blocklen(drbg), prefix, 1);
+ crypto_inc(drbg-V, drbg_blocklen(drbg));
drbg_string_fill(data, drbg-V, drbg_blocklen(drbg));
while (len buflen) {
int outlen = 0;
@@ -643,7 +609,7 @@ static int drbg_ctr_generate(struct drbg_state *drbg,
drbg_blocklen(drbg) : (buflen - len);
if (!drbg_fips_continuous_test(drbg, drbg-scratchpad)) {
/* 10.2.1.5.2 step 6 */
- drbg_add_buf(drbg-V, drbg_blocklen(drbg), prefix, 1);
+ crypto_inc(drbg-V, drbg_blocklen(drbg));
continue;
}
/* 10.2.1.5.2 step 4.3 */
@@ -651,7 +617,7 @@ static int drbg_ctr_generate(struct drbg_state *drbg,
len += outlen;
/* 10.2.1.5.2 step 6 */
if (len buflen)
- drbg_add_buf(drbg-V, drbg_blocklen(drbg), prefix, 1);
+ crypto_inc(drbg-V, drbg_blocklen(drbg));
}
/* 10.2.1.5.2 step 6 */
@@ -797,6 +763,38 @@ static struct drbg_state_ops drbg_hmac_ops = {
#ifdef CONFIG_CRYPTO_DRBG_HASH
#define CRYPTO_DRBG_HASH_STRING HASH
/*
+ * Increment buffer
+ *
+ * @dst buffer to increment
+ * @add value to add
+ */
+static inline void drbg_add_buf(unsigned char *dst, size_t dstlen,
+ const unsigned char *add, size_t addlen)
+{
+ /* implied: dstlen addlen */
+ unsigned char *dstptr;
+ const unsigned char *addptr;
+ unsigned int remainder = 0;
+ size_t len = addlen;
+
+ dstptr = dst + (dstlen-1);
+ addptr = add + (addlen-1);
+ while (len) {
+ remainder += *dstptr + *addptr;
+ *dstptr = remainder 0xff;
+ remainder = 8;
+ len--; dstptr--; addptr--;
+ }
+ len = dstlen - addlen;
+ while (len remainder 0) {
+ remainder = *dstptr + 1;
+ *dstptr = remainder 0xff;
+
Re: [PATCH] kernel crypto API interface specification
Am Dienstag, 14. Oktober 2014, 21:46:50 schrieb Stephan Mueller: Hi, The update adds a complete interface documentation of the kernel crypto API. All cipher types supported by the kernel crypto API are documented. In addition, kernel and user space example code is provided. The sample code covers synchronous and asynchronous cipher operation, random number generation and performing hashing as well as encryption and decryption in user space. I was not sure whether to cover the explanation of the API in a separate document or whether to add the function documentation to include/linux/crypto.h. With the first attempt of the documentation, I applied the least invasive approach. If it is requested, I would modify the patch such that appropriate source code comments to the functions in the header file are added. -- Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
