Re: [PATCH] crypto: caam: Introduce the use of the managed version of kzalloc
On Tuesday, May 27, 2014 at 08:25:48 PM, Himangi Saraogi wrote: > This patch moves data allocated using kzalloc to managed data allocated > using devm_kzalloc and cleans now unnecessary kfrees in probe and remove > functions. Also, linux/device.h is added to make sure the devm_*() > routine declarations are unambiguously available. Earlier, in the probe > function ctrlpriv was leaked on the failure of ctrl = of_iomap(nprop, 0); > as well as on the failure of ctrlpriv->jrpdev = kzalloc(...); . These > two bugs have been fixed by the patch. > > The following Coccinelle semantic patch was used for making the change: Reviewed-by: Marek Vasut Best regards, Marek Vasut -- 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: RFC: 2 pages are enough for xor speed testing
On Wednesday, May 28, 2014 at 07:01:52 AM, Amos Kong wrote: > @@ -154,7 +154,7 @@ calibrate_xor_blocks(void) > #undef xor_speed > > out: > - free_pages((unsigned long)b1, 2); > + free_pages((unsigned long)b1, 1); > > active_template = fastest; > return 0; I suppose this part of the patch was not intentional ;-) Best regards, Marek Vasut -- 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: Crash when using ahash_request_ctx
On Wednesday, May 28, 2014 at 12:01:09 PM, Corentin LABBE wrote:
> Hello
>
> I have a problem when using a simple md5 tfm.
> When I use the data that ahash_request_ctx() give me, it will cause random
> crash when removing the module later. I do not understand it, because
> .cra_ctxsize seems to be rightly used.
>
> The very simplified POC code will follow, it register a fake md5
> implementation. If I remove the op->mode = 0, I can modprobe/rmmod for
> ever without problem. With it, rmmod will segfault in 2 or 3 tries, so it
> is this write that is the source of the problem.
>
> I have try to debug, but I cannot find where __ctx (the pointer returned by
> ahash_request_ctx) is allocated.
>
> Does I am right when saying: ahash_request_ctx() return the pointer to a
> structure of size equal to cra_ctxsize allocated for each request ?
crypto_tfm_ctx() returns per-transformation instance (tfm) private data
ahash_request_ctx() returns per-request private data
You need to configure the request context size via crypto_ahash_set_reqsize()
in
the implementations' .cra_init() callback .
[...]
static int my_cra_init(struct crypto_tfm *tfm)
{
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
sizeof(struct my_per_request_private_data));
return 0;
}
> static struct ahash_alg sunxi_md5_alg = {
> .init = fake_init,
> .update = fake_update,
> .final = fake_final,
> .finup = fake_finup,
> .digest = fake_digest,
> .halg = {
> .digestsize = MD5_DIGEST_SIZE,
> .base = {
> .cra_name = "md5",
> .cra_driver_name = "md5-sunxi-ss",
> .cra_priority = 300,
> .cra_alignmask = 3,
> .cra_flags = CRYPTO_ALG_TYPE_AHASH | CRYPTO_ALG_ASYNC,
> .cra_blocksize = MD5_HMAC_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct sunxi_req_ctx),
> .cra_module = THIS_MODULE,
> .cra_type = &crypto_ahash_type
.cra_init = my_cra_init,
> }
> }
> };
>
> static int sunxi_ss_md5_init(void)
> {
> int err = 0;
> err = crypto_register_ahash(&sunxi_md5_alg);
> if (err)
> pr_err("crypto_register_alg error for MD5\n");
> else
> pr_info("Registred MD5\n");
> return err;
> }
>
> static void __exit sunxi_ss_md5_exit(void)
> {
> crypto_unregister_ahash(&sunxi_md5_alg);
> }
>
> module_init(sunxi_ss_md5_init);
> module_exit(sunxi_ss_md5_exit);
module_platform_driver() here please, fix it up so this is a platform driver.
--
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 v9 0/6] SP800-90A Deterministic Random Bit Generator
Hi, the following set of patches implements the deterministic random bit generator (DRBG) specified by SP800-90A. The DRBG implementation offers the following: * All three DRBG types are implemented with a derivation function. * All DRBG types are available with and without prediction resistance. * All SHA types of SHA-1, SHA-256, SHA-384, SHA-512 are available for the HMAC and Hash DRBGs. * All AES types of AES-128, AES-192 and AES-256 are available for the CTR DRBG. * A self test is implemented with drbg_healthcheck(). * The FIPS 140-2 continuous self test is implemented. * Additional cipher primitives, such as Serpent or Twofish, can be added to the DRBG without changing the implementation. The only change necessary is to the DRBG definition given in the cores[] array. As defined in SP800-131A, the ANSI X9.31 DRNG is to be sunset by the end of this year for official uses, including FIPS 140-2 compliance. Additional tests including the CAVS test framework are available at [1]. [1] http://www.chronox.de/drbg.html Changes v2: * Overhauling code structure for simpler code as suggested by Rafael Aquini: - each DRBG type exports only two crypto functions, - the individual DRBG implementations structure closely according to SP 800-90A, - using struct drbg_string to refer to buffers to avoid too many function parameters and prevent multiple data structure conversions - use inline more thoroughly - replace macros with small inline functions - remove unnecessary indirections - replace of large stack variables with a scratch buffer allocated at the beginning of DRBG operation -- see comments about scratchpad throughout the code * Revamping DRBG flags usage: flags are only intended to select the appropriate DRBG type and DRBG strength. Flags are not intended to be visible to external callers. * Adding comments throughout the code to refer to the appropriate steps documented in SP 800-90A. * Fix invocation of kernel crypto API hash * Fix coding style and apply scripts/checkpatch.pl * Change locking approach: only very small code sections are guarded by a lock. This implies that the entire DRBG operates on a shadow copy of the original DRBG state -- see comments for drbg_copy_drbg * Perform thorough testing: - Performing of a full scale CAVS test with CAVS interface available at http://www.chronox.de/drbg.html - Performing tests by obtaining data which is not a multiple of cipher block size and check it with the ent tool to ensure that the generation loop does not reuse stale buffers to avoid errors like CVE-2013-4345. Changes v3: * fix invocation of drbg_sec_strength to determine the amount of seed needed for the DRBG. The function returns information as a byte value, but the invoker assumed a bit value. * change default value returned by drbg_sec_strength to be the maximum entropy defined by SP800-90A to catch erroneous invocations of the function. * Fix invocaction of d_ops in drbg_generate: drbg->d_ops ==> shadow->d_ops * Make return of drbg_fips_continuous_test cleaner as suggested by Clemens Ladisch * Fix comments on how to invoke the DRBG at the beginning of the file drbg_ctr_df: replace the for loop for calculation of padlen that used to call up to 16 modulo operations with one modulo operation * drbg_ctr_df: replace plain integer values with sizeof() to make code clearer * drbg_hash_hashgen: replace memset() on drbg->scratchpad with memset() on src/dst pointers to make code clearer * as recommended by Peter Waltenberg: add re-invocation of self tests as required by 11.3.3 -- the tests are commented out because they make no mathematical sense. However, if a FIPS 140-2 validation requires these tests, the code just needs to be activated. * as recommended by Peter Waltenberg: add error path tests as required by 11.3.2 -- see new function of drbg_healthcheck_sanity * add debug printk * perform testing in FIPS 140-2 mode * as recommended by Peter Waltenberg: add drbg_generate_long to generate arbitrary long strings Changes v4: * change return codes of generate functions to signed int to convey error codes and to match the kernel crypto API expectations on the generate function. * add BUG_ON throughout drbg_healthcheck_sanity() since any failure should be caught to prevent the DRBG from operating * change layout of debugging printk Changes v5: * make numerous character buffer pointers and drbg_string pointers const as suggested by Joe Perches Changes v6: * change name of array cores to drbg_cores as suggested by Joe Perches * make drbg_cores static as suggested by Joe Perches * catch programming error regarding array overflow in drbg_algs gracefully Changes v7: * editorial changes: cleanu
[PATCH v9 2/6] header file for DRBG
The header file includes the definition of:
* DRBG data structures with
- struct drbg_state as main structure
- struct drbg_core referencing the backend ciphers
- struct drbg_state_ops callbach handlers for specific code
supporting the Hash, HMAC, CTR DRBG implementations
- struct drbg_conc defining a linked list for input data
- struct drbg_test_data holding the test "entropy" data for CAVS
testing and testmgr.c
- struct drbg_gen allowing test data, additional information
string and personalization string data to be funneled through
the kernel crypto API -- the DRBG requires additional
parameters when invoking the reset and random number
generation requests than intended by the kernel crypto API
* wrapper function to the kernel crypto API functions using struct
drbg_gen to pass through all data needed for DRBG
* wrapper functions to kernel crypto API functions usable for testing
code to inject test_data into the DRBG as needed by CAVS testing and
testmgr.c.
* DRBG flags required for the operation of the DRBG and for selecting
the particular DRBG type and backend cipher
* getter functions for data from struct drbg_core
Signed-off-by: Stephan Mueller
---
include/crypto/drbg.h | 289 ++
1 file changed, 289 insertions(+)
create mode 100644 include/crypto/drbg.h
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
new file mode 100644
index 000..b507c5b6
--- /dev/null
+++ b/include/crypto/drbg.h
@@ -0,0 +1,289 @@
+/*
+ * DRBG based on NIST SP800-90A
+ *
+ * Copyright Stephan Mueller , 2014
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, and the entire permission notice in its entirety,
+ *including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ *products derived from this software without specific prior
+ *written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL are
+ * required INSTEAD OF the above restrictions. (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+#ifndef _DRBG_H
+#define _DRBG_H
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Concatenation Helper and string operation helper
+ *
+ * SP800-90A requires the concatenation of different data. To avoid copying
+ * buffers around or allocate additional memory, the following data structure
+ * is used to point to the original memory with its size. In addition, it
+ * is used to build a linked list. The linked list defines the concatenation
+ * of individual buffers. The order of memory block referenced in that
+ * linked list determines the order of concatenation.
+ */
+struct drbg_string {
+ const unsigned char *buf;
+ size_t len;
+ struct drbg_string *next;
+};
+
+static inline void drbg_string_fill(struct drbg_string *string,
+ const unsigned char *buf, size_t len)
+{
+ string->buf = buf;
+ string->len = len;
+ string->next = NULL;
+}
+
+struct drbg_state;
+typedef uint32_t drbg_flag_t;
+
+struct drbg_core {
+ drbg_flag_t flags; /* flags for the cipher */
+ __u8 statelen; /* maximum state length */
+ /*
+* maximum length of personalization string or additional input
+* string -- exponent for base 2
+*/
+ __u8 max_addtllen;
+ /* maximum bits per RNG request -- exponent for base 2*/
+ __u8 max_bits;
+ /* maximu
[PATCH v9 4/6] compile the DRBG code
Signed-off-by: Stephan Mueller --- crypto/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/Makefile b/crypto/Makefile index 38e64231..bfa94fa 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -92,6 +92,7 @@ obj-$(CONFIG_CRYPTO_842) += 842.o obj-$(CONFIG_CRYPTO_RNG2) += rng.o obj-$(CONFIG_CRYPTO_RNG2) += krng.o obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o +obj-$(CONFIG_CRYTPO_DRBG) += drbg.o obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o -- 1.9.3 -- 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 v9 3/6] DRBG kernel configuration options
The different DRBG types of CTR, Hash, HMAC can be enabled or disabled at compile time. At least one DRBG type shall be selected. The default is the HMAC DRBG as its code base is smallest. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 36 +++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index ce4012a..c9c1cd9 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -23,7 +23,7 @@ comment "Crypto core or helper" config CRYPTO_FIPS bool "FIPS 200 compliance" - depends on CRYPTO_ANSI_CPRNG && !CRYPTO_MANAGER_DISABLE_TESTS + depends on (CRYPTO_ANSI_CPRNG || CRYTPO_DRBG) && !CRYPTO_MANAGER_DISABLE_TESTS help This options enables the fips boot option which is required if you want to system to operate in a FIPS 200 @@ -1380,6 +1380,40 @@ config CRYPTO_ANSI_CPRNG ANSI X9.31 A.2.4. Note that this option must be enabled if CRYPTO_FIPS is selected +menuconfig CRYTPO_DRBG + tristate "NIST SP800-90A DRBG" + depends on CRYPTO + select CRYPTO_RNG + help + NIST SP800-90A compliant DRBG. In the following submenu, one or + more of the DRBG types must be selected. + +if CRYTPO_DRBG + +config CRYPTO_DRBG_HMAC + bool "Enable HMAC DRBG" + default y + depends on CRYTPO_DRBG + select CRYPTO_HMAC + help + Enable the HMAC DRBG variant as defined in NIST SP800-90A. + +config CRYPTO_DRBG_HASH + bool "Enable Hash DRBG" + depends on CRYTPO_DRBG + select CRYPTO_HASH + help + Enable the Hash DRBG variant as defined in NIST SP800-90A. + +config CRYPTO_DRBG_CTR + bool "Enable CTR DRBG" + depends on CRYTPO_DRBG + select CRYPTO_AES + help + Enable the CTR DRBG variant as defined in NIST SP800-90A. + +endif #CRYTPO_DRBG + config CRYPTO_USER_API tristate -- 1.9.3 -- 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 v9 5/6] DRBG testmgr test vectors
All types of the DRBG (CTR, HMAC, Hash) are covered with test vectors.
In addition, all permutations of use cases of the DRBG are covered:
* with and without predition resistance
* with and without additional information string
* with and without personalization string
As the DRBG implementation is agnositc of the specific backend cipher,
only test vectors for one specific backend cipher is used. For example:
the Hash DRBG uses the same code paths irrespectively of using SHA-256
or SHA-512. Thus, the test vectors for SHA-256 cover the testing of all
DRBG code paths of SHA-512.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.h | 843 +++
1 file changed, 843 insertions(+)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 3db83db..0030ff5 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -92,6 +92,21 @@ struct cprng_testvec {
unsigned short loops;
};
+struct drbg_testvec {
+ unsigned char *entropy;
+ size_t entropylen;
+ unsigned char *entpra;
+ unsigned char *entprb;
+ size_t entprlen;
+ unsigned char *addtla;
+ unsigned char *addtlb;
+ size_t addtllen;
+ unsigned char *pers;
+ size_t perslen;
+ unsigned char *expected;
+ size_t expectedlen;
+};
+
static char zeroed_string[48];
/*
@@ -19342,6 +19357,834 @@ static struct cprng_testvec
ansi_cprng_aes_tv_template[] = {
},
};
+/*
+ * SP800-90A DRBG Test vectors from
+ * http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgtestvectors.zip
+ *
+ * Test vectors for DRBG with prediction resistance. All types of DRBGs
+ * (Hash, HMAC, CTR) are tested with all permutations of use cases (w/ and
+ * w/o personalization string, w/ and w/o additional input string).
+ */
+static struct drbg_testvec drbg_pr_sha256_tv_template[] = {
+ {
+ .entropy = (unsigned char *)
+ "\x72\x88\x4c\xcd\x6c\x85\x57\x70\xf7\x0b\x8b\x86"
+ "\xc1\xeb\xd2\x4e\x36\x14\xab\x18\xc4\x9c\xc9\xcf"
+ "\x1a\xe8\xf7\x7b\x02\x49\x73\xd7\xf1\x42\x7d\xc6"
+ "\x3f\x29\x2d\xec\xd3\x66\x51\x3f\x1d\x8d\x5b\x4e",
+ .entropylen = 48,
+ .entpra = (unsigned char *)
+ "\x38\x9c\x91\xfa\xc2\xa3\x46\x89\x56\x08\x3f\x62"
+ "\x73\xd5\x22\xa9\x29\x63\x3a\x1d\xe5\x5d\x5e\x4f"
+ "\x67\xb0\x67\x7a\x5e\x9e\x0c\x62",
+ .entprb = (unsigned char *)
+ "\xb2\x8f\x36\xb2\xf6\x8d\x39\x13\xfa\x6c\x66\xcf"
+ "\x62\x8a\x7e\x8c\x12\x33\x71\x9c\x69\xe4\xa5\xf0"
+ "\x8c\xee\xeb\x9c\xf5\x31\x98\x31",
+ .entprlen = 32,
+ .expected = (unsigned char *)
+ "\x52\x7b\xa3\xad\x71\x77\xa4\x49\x42\x04\x61\xc7"
+ "\xf0\xaf\xa5\xfd\xd3\xb3\x0d\x6a\x61\xba\x35\x49"
+ "\xbb\xaa\xaf\xe4\x25\x7d\xb5\x48\xaf\x5c\x18\x3d"
+ "\x33\x8d\x9d\x45\xdf\x98\xd5\x94\xa8\xda\x92\xfe"
+ "\xc4\x3c\x94\x2a\xcf\x7f\x7b\xf2\xeb\x28\xa9\xf1"
+ "\xe0\x86\x30\xa8\xfe\xf2\x48\x90\x91\x0c\x75\xb5"
+ "\x3c\x00\xf0\x4d\x09\x4f\x40\xa7\xa2\x8c\x52\xdf"
+ "\x52\xef\x17\xbf\x3d\xd1\xa2\x31\xb4\xb8\xdc\xe6"
+ "\x5b\x0d\x1f\x78\x36\xb4\xe6\x4b\xa7\x11\x25\xd5"
+ "\x94\xc6\x97\x36\xab\xf0\xe5\x31\x28\x6a\xbb\xce"
+ "\x30\x81\xa6\x8f\x27\x14\xf8\x1c",
+ .expectedlen = 128,
+ .addtla = NULL,
+ .addtlb = NULL,
+ .addtllen = 0,
+ .pers = NULL,
+ .perslen = 0,
+ }, {
+ .entropy = (unsigned char *)
+ "\x5d\xf2\x14\xbc\xf6\xb5\x4e\x0b\xf0\x0d\x6f\x2d"
+ "\xe2\x01\x66\x7b\xd0\xa4\x73\xa4\x21\xdd\xb0\xc0"
+ "\x51\x79\x09\xf4\xea\xa9\x08\xfa\xa6\x67\xe0\xe1"
+ "\xd1\x88\xa8\xad\xee\x69\x74\xb3\x55\x06\x9b\xf6",
+ .entropylen = 48,
+ .entpra = (unsigned char *)
+ "\xef\x48\x06\xa2\xc2\x45\xf1\x44\xfa\x34\x2c\xeb"
+ "\x8d\x78\x3c\x09\x8f\x34\x72\x20\xf2\xe7\xfd\x13"
+ "\x76\x0a\xf6\xdc\x3c\xf5\xc0\x15",
+ .entprb = (unsigned char *)
+ "\x4b\xbe\xe5\x24\xed\x6a\x2d\x0c\xdb\x73\x5e\x09"
+ "\xf9\xad\x67\x7c\x51\x47\x8b\x6b\x30\x2a\xc6\xde"
+ "\x76\xaa\x55\x04\x8b\x0a\x72\x95",
+ .entprlen = 32,
+ .expected = (unsigned char *)
+ "\x3b\x14\x71\x99\xa1\xda\xa0\x42\xe6\xc8\x85\x32"
+ "\x70\x20\x32\x53\x9a\xbe\xd1\x1e\x15\xef\xfb\x4c"
+
[PATCH v9 6/6] Add DRBG test code to testmgr
The DRBG test code implements the CAVS test approach.
As discussed for the test vectors, all DRBG types are covered with
testing. However, not every backend cipher is covered with testing. To
prevent the testmgr from logging missing testing, the NULL test is
registered for all backend ciphers not covered with specific test cases.
All currently implemented DRBG types and backend ciphers are defined
in SP800-90A. Therefore, the fips_allowed flag is set for all.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.c | 247 +++
1 file changed, 247 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index dc3cf35..4b1f512 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "internal.h"
@@ -108,6 +109,11 @@ struct cprng_test_suite {
unsigned int count;
};
+struct drbg_test_suite {
+ struct drbg_testvec *vecs;
+ unsigned int count;
+};
+
struct alg_test_desc {
const char *alg;
int (*test)(const struct alg_test_desc *desc, const char *driver,
@@ -121,6 +127,7 @@ struct alg_test_desc {
struct pcomp_test_suite pcomp;
struct hash_test_suite hash;
struct cprng_test_suite cprng;
+ struct drbg_test_suite drbg;
} suite;
};
@@ -1712,6 +1719,100 @@ static int alg_test_cprng(const struct alg_test_desc
*desc, const char *driver,
return err;
}
+
+static int drbg_cavs_test(struct drbg_testvec *test, int pr,
+ const char *driver, u32 type, u32 mask)
+{
+ int ret = -EAGAIN;
+ struct crypto_rng *drng;
+ struct drbg_test_data test_data;
+ struct drbg_string addtl, pers, testentropy;
+ unsigned char *buf = kzalloc(test->expectedlen, GFP_KERNEL);
+
+ if (!buf)
+ return -ENOMEM;
+
+ drng = crypto_alloc_rng(driver, type, mask);
+ if (IS_ERR(drng)) {
+ printk(KERN_ERR "alg: drbg: could not allocate DRNG handle for"
+ "%s\n", driver);
+ kzfree(buf);
+ return -ENOMEM;
+ }
+
+ test_data.testentropy = &testentropy;
+ drbg_string_fill(&testentropy, test->entropy, test->entropylen);
+ drbg_string_fill(&pers, test->pers, test->perslen);
+ ret = crypto_drbg_reset_test(drng, &pers, &test_data);
+ if (ret) {
+ printk(KERN_ERR "alg: drbg: Failed to reset rng\n");
+ goto outbuf;
+ }
+
+ drbg_string_fill(&addtl, test->addtla, test->addtllen);
+ if (pr) {
+ drbg_string_fill(&testentropy, test->entpra, test->entprlen);
+ ret = crypto_drbg_get_bytes_addtl_test(drng,
+ buf, test->expectedlen, &addtl, &test_data);
+ } else {
+ ret = crypto_drbg_get_bytes_addtl(drng,
+ buf, test->expectedlen, &addtl);
+ }
+ if (ret <= 0) {
+ printk(KERN_ERR "alg: drbg: could not obtain random data for"
+ "driver %s\n", driver);
+ goto outbuf;
+ }
+
+ drbg_string_fill(&addtl, test->addtlb, test->addtllen);
+ if (pr) {
+ drbg_string_fill(&testentropy, test->entprb, test->entprlen);
+ ret = crypto_drbg_get_bytes_addtl_test(drng,
+ buf, test->expectedlen, &addtl, &test_data);
+ } else {
+ ret = crypto_drbg_get_bytes_addtl(drng,
+ buf, test->expectedlen, &addtl);
+ }
+ if (ret <= 0) {
+ printk(KERN_ERR "alg: drbg: could not obtain random data for"
+ "driver %s\n", driver);
+ goto outbuf;
+ }
+
+ ret = memcmp(test->expected, buf, test->expectedlen);
+
+outbuf:
+ crypto_free_rng(drng);
+ kzfree(buf);
+ return ret;
+}
+
+
+static int alg_test_drbg(const struct alg_test_desc *desc, const char *driver,
+u32 type, u32 mask)
+{
+ int err = 0;
+ int pr = 0;
+ int i = 0;
+ struct drbg_testvec *template = desc->suite.drbg.vecs;
+ unsigned int tcount = desc->suite.drbg.count;
+
+ if (0 == memcmp(driver, "drbg_pr_", 8))
+ pr = 1;
+
+ for (i = 0; i < tcount; i++) {
+ err = drbg_cavs_test(&template[i], pr, driver, type, mask);
+ if (err) {
+ printk(KERN_ERR "alg: drbg: Test %d failed for %s\n",
+ i, driver);
+ err = -EINVAL;
+ break;
+ }
+ }
+ return err;
+
+}
+
static int alg_test_null(const struct alg_test_desc *desc,
const char *driver, u32 type, u32 mask)
{
@@ -2305,6 +2406,152 @@ static const struct alg_test_desc alg_test_descs[] = {
.alg = "digest_null",
.test
