[PATCH v2 4/6] compile the DRBG code
Signed-off-by: Stephan Mueller smuel...@chronox.de --- diff --git a/crypto/Makefile b/crypto/Makefile index b29402a..0d63373 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.8.5.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 v2 1/6] SP800-90A Deterministic Random Bit Generator
This is a clean-room implementation of the DRBG defined in SP800-90A. All three viable DRBGs defined in the standard are implemented: * HMAC: This is the leanest DRBG and compiled per default * Hash: The more complex DRBG can be enabled at compile time * CTR: The most complex DRBG can also be enabled at compile time 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. Changes to v1: * 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. Signed-off-by: Stephan Mueller smuel...@chronox.de --- create mode 100644 crypto/drbg.c diff --git a/crypto/drbg.c b/crypto/drbg.c new file mode 100644 index 000..808852b --- /dev/null +++ b/crypto/drbg.c @@ -0,0 +1,1790 @@ +/* + * DRBG: Deterministic Random Bits Generator + * Based on NIST Recommended DRBG from NIST SP800-90A with the following + * properties: + * * CTR DRBG with DF with AES-128, AES-192, AES-256 cores + * * Hash DRBG with DF with SHA-1, SHA-256, SHA-384, SHA-512 cores + * * HMAC DRBG with DF with SHA-1, SHA-256, SHA-384, SHA-512 cores + * * with and without prediction resistance + * + * Copyright Stephan Mueller smuel...@chronox.de, 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
[PATCH v2 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.
Changes to v1:
* Fix coding style and apply scripts/checkpatch.pl
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 7d44aa3..1f48312 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -92,6 +92,29 @@ struct cprng_testvec {
unsigned short loops;
};
+struct drbg_testvec {
+ unsigned char *entropy; /* entropy string for initialization -- this
+* string is a concatenation of the entropy
+* and nonce variable from CAVS */
+ size_t entropylen; /* length of entropy and nonce variable */
+ unsigned char *entpra; /* for prediction resistance: entropy for
+* first reseeding */
+ unsigned char *entprb; /* for prediction resistance: entropy for
+* second reseeding */
+ size_t entprlen;/* length of prediction resistance entropy */
+ unsigned char *addtla; /* additional input string for first random
+* value */
+ unsigned char *addtlb; /* additional input string for second random
+* value */
+ size_t addtllen;/* length of additional input string */
+ unsigned char *pers;/* personalization string */
+ size_t perslen; /* personalization string length */
+ unsigned char *expected; /* expected random value -- for CAVS test,
+ this value does not apply and the memcmp
+ in drbg_cavs_test does not apply either*/
+ size_t expectedlen; /* length of expected random value */
+};
+
static char zeroed_string[48];
/*
@@ -19162,6 +19185,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
+
[PATCH v2 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 smuel...@chronox.de --- diff --git a/crypto/Kconfig b/crypto/Kconfig index 7bcb70d..2cdf9c6 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.8.5.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 v2 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_string 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
Changes to v1:
* Changes due to modification of drbg.c as documented in PATCH 1
* Fix coding style and apply scripts/checkpatch.pl
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
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..f52e7ca
--- /dev/null
+++ b/include/crypto/drbg.h
@@ -0,0 +1,292 @@
+/*
+ * DRBG based on NIST SP800-90A
+ *
+ * Copyright Stephan Mueller smuel...@chronox.de, 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 linux/random.h
+#include linux/scatterlist.h
+#include crypto/hash.h
+#include linux/module.h
+#include linux/crypto.h
+#include linux/slab.h /* needed for kzalloc */
+#include crypto/internal/rng.h
+#include crypto/rng.h
+#include linux/fips.h
+#include linux/spinlock.h
+
+/*
+ * 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 */
+ __u8 max_addtllen; /*
[PATCH v2 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 definined
in SP800-90A. Therefore, the fips_allowed flag is set for all.
Changes to v1:
* Changes due to modification of drbg.c as documented in PATCH 1
* Fix coding style and apply scripts/checkpatch.pl
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 7795550..baa6cb7 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/string.h
#include crypto/rng.h
+#include crypto/drbg.h
#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,101 @@ 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)) ||
+ (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)
{
@@ -2273,6 +2375,171 @@ static const struct
Re: [PATCH][RESEND 3] hwrng: add randomness to system from rng sources
On 2014-03-16 18:56, H. Peter Anvin wrote: On 03/03/2014 03:51 PM, Kees Cook wrote: When bringing a new RNG source online, it seems like it would make sense to use some of its bytes to make the system entropy pool more random, as done with all sorts of other devices that contain per-device or per-boot differences. Signed-off-by: Kees Cook keesc...@chromium.org I would like to raise again the concept of at least optionally using a kernel thread, rather than a user-space daemon, to feed hwrng output to the kernel pools. The main service rngd provides is FIPS tests, but those FIPS tests were withdrawn as a standard over 10 years ago and are known to be extremely weak, at the very best a minimal sanity check. Furthermore, they are completely useless against the output of any RNG which contains a cryptographic whitener, which is the vast majority of commercial sources -- this is especially so since rngd doesn't expect to have to do any data reduction for output coming from hwrng. Furthermore, if more than one hwrng device is available, rngd will only be able to read one of them because of the way /dev/hwrng is implemented in the kernel. For contrast, the kernel could do data reduction just fine by only crediting the entropy coming out of each hwrng driver with a fractional amount. That does *not* mean that there aren't random number generators which require significant computation better done in user space. For example, an audio noise daemon or a lava lamp camera which requires video processing. -hpa I definitely second this proposal, not only does it get rid of the overhead of the FIPS tests (which can be quite significant on embedded systems), it also removes a significant percentage of the context switches that rngd needs to make. This should provide some way of disabling this behavior, probably either making it a module, or providing a command-line/sysfs option to disable it. In fact, it should probably default to being disabled (at least at first) and require the user to explicitly opt-in to using it (I know people who run simulations who use the output from /dev/hwrng directly for the simulation software exclusively, and /dev/[u]random for everything else). -- 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 2/2] SHA1 transform: x86_64 AVX2 optimization - glue build-v2
On Fri, 2014-03-14 at 06:40 +0100, Marek Vasut wrote: On Wednesday, March 12, 2014 at 07:47:50 PM, chandramouli narayanan wrote: This git patch adds the glue, build and configuration changes to include x86_64 AVX2 optimization of SHA1 transform to crypto support. The patch has been tested with 3.14.0-rc1 kernel. Changes from the initial version of this patch are in a) check for BMI2 in addition to AVX2 support since __sha1_transform_avx2() uses rorx b) Since the module build has dependency on 64bit, it is redundant to check it in the code here. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, tcrypt shows AVX2 performance improvement from 3% for 256 bytes update to 16% for 1024 bytes update over AVX implementation. Signed-off-by: Chandramouli Narayanan mo...@linux.intel.com diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile index 6ba54d6..61d6e28 100644 --- a/arch/x86/crypto/Makefile +++ b/arch/x86/crypto/Makefile @@ -79,6 +79,9 @@ aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o fpu.o aesni-intel-$(CONFIG_64BIT) += aesni-intel_avx-x86_64.o ghash-clmulni-intel-y := ghash-clmulni-intel_asm.o ghash-clmulni-intel_glue.o sha1-ssse3-y := sha1_ssse3_asm.o sha1_ssse3_glue.o +ifeq ($(avx2_supported),yes) +sha1-ssse3-y += sha1_avx2_x86_64_asm.o Use: sha1-ssse3-$(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o And you will not need the CONFIG_AS_AVX2 ifdef in your previous patch, no ? [...] Best regards, Marek Vasut Sorry for the delayed reply. Agreed, I will fix the dependency. thanks - mouli -- 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 1/2] SHA1 transform: x86_64 AVX2 optimization - assembly code-v2
On Fri, 2014-03-14 at 06:34 +0100, Marek Vasut wrote: On Wednesday, March 12, 2014 at 07:47:43 PM, chandramouli narayanan wrote: This git patch adds x86_64 AVX2 optimization of SHA1 transform to crypto support. The patch has been tested with 3.14.0-rc1 kernel. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, tcrypt shows AVX2 performance improvement from 3% for 256 bytes update to 16% for 1024 bytes update over AVX implementation. Signed-off-by: Chandramouli Narayanan mo...@linux.intel.com diff --git a/arch/x86/crypto/sha1_avx2_x86_64_asm.S b/arch/x86/crypto/sha1_avx2_x86_64_asm.S new file mode 100644 index 000..2f71294 --- /dev/null +++ b/arch/x86/crypto/sha1_avx2_x86_64_asm.S @@ -0,0 +1,732 @@ +/* + Implement fast SHA-1 with AVX2 instructions. (x86_64) + + This file is provided under a dual BSD/GPLv2 license. When using or + redistributing this file, you may do so under either license. + + GPL LICENSE SUMMARY Please see Documentation/CodingStyle chapter 8 for the preffered comment style. I will fix the coding style issues. [...] +*/ + +#- +# +#SHA-1 implementation with Intel(R) AVX2 instruction set extensions. DTTO here. I will fix style issues. +#This implementation is based on the previous SSSE3 release: +#Visit http://software.intel.com/en-us/articles/ +#and refer to improving-the-performance-of-the-secure-hash-algorithm-1/ +# +#Updates 20-byte SHA-1 record in 'hash' for even number of +#'num_blocks' consecutive 64-byte blocks +# +#extern C void sha1_transform_avx2( +# int *hash, const char* input, size_t num_blocks ); +# + +#ifdef CONFIG_AS_AVX2 I wonder, is this large #ifdef around the entire file needed here? Can you not just handle not-compiling this file in in the Makefile ? [...] +push %rbx +push %rbp +push %r12 +push %r13 +push %r14 +push %r15 + #FIXME: Save rsp + +RESERVE_STACK = (W_SIZE*4 + 8+24) + +# Align stack +mov %rsp, %rbx +and $(0x1000-1), %rbx +sub $(8+32), %rbx +sub %rbx, %rsp +push%rbx +sub $RESERVE_STACK, %rsp + +avx2_zeroupper + + lea K_XMM_AR(%rip), K_BASE Can you please use TABs for indent consistently (see the CodingStyle again) ? Agreed. [...] +.align 32 +_loop: + # code loops through more than one block + # we use K_BASE value as a signal of a last block, + # it is set below by: cmovae BUFFER_PTR, K_BASE +cmp K_BASE, BUFFER_PTR +jne _begin +.align 32 +jmp _end +.align 32 +_begin: + +# Do first block +RR 0 +RR 2 +RR 4 +RR 6 +RR 8 + +jmp _loop0 +_loop0: + +RR 10 +RR 12 +RR 14 +RR 16 +RR 18 + +RR 20 +RR 22 +RR 24 +RR 26 +RR 28 Can you not generate these repeated sequences with some of the AS's macro voodoo ? Like .rept or somesuch ? Will incorporate a .rept. [...] +.macro UPDATE_HASH hash, val + add \hash, \val + mov \val, \hash +.endm This macro is defined below the point where it's used, which is a little counter-intuitive. [...] Will reorganize. + +/* AVX2 optimized implementation: + * extern C void sha1_transform_avx2( + * int *hash, const char* input, size_t num_blocks ); What does this comment tell me ? btw. you might want to squash 1/2 and 2/2 , since they are not two logical separate blocks I think. In summary, I will fix these issues, retest and post the next version. thanks, - mouli -- 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 2/2] SHA1 transform: x86_64 AVX2 optimization - glue build-v2
On Monday, March 17, 2014 at 04:53:12 PM, chandramouli narayanan wrote: On Fri, 2014-03-14 at 06:40 +0100, Marek Vasut wrote: On Wednesday, March 12, 2014 at 07:47:50 PM, chandramouli narayanan wrote: This git patch adds the glue, build and configuration changes to include x86_64 AVX2 optimization of SHA1 transform to crypto support. The patch has been tested with 3.14.0-rc1 kernel. Changes from the initial version of this patch are in a) check for BMI2 in addition to AVX2 support since __sha1_transform_avx2() uses rorx b) Since the module build has dependency on 64bit, it is redundant to check it in the code here. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, tcrypt shows AVX2 performance improvement from 3% for 256 bytes update to 16% for 1024 bytes update over AVX implementation. Signed-off-by: Chandramouli Narayanan mo...@linux.intel.com diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile index 6ba54d6..61d6e28 100644 --- a/arch/x86/crypto/Makefile +++ b/arch/x86/crypto/Makefile @@ -79,6 +79,9 @@ aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o fpu.o aesni-intel-$(CONFIG_64BIT) += aesni-intel_avx-x86_64.o ghash-clmulni-intel-y := ghash-clmulni-intel_asm.o ghash-clmulni-intel_glue.o sha1-ssse3-y := sha1_ssse3_asm.o sha1_ssse3_glue.o +ifeq ($(avx2_supported),yes) +sha1-ssse3-y += sha1_avx2_x86_64_asm.o Use: sha1-ssse3-$(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o And you will not need the CONFIG_AS_AVX2 ifdef in your previous patch, no ? [...] Best regards, Marek Vasut Sorry for the delayed reply. Agreed, I will fix the dependency. No problem, thanks! 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: [PATCH 2/2] SHA1 transform: x86_64 AVX2 optimization - glue build-v2
On Mon, 2014-03-17 at 17:06 +0100, Marek Vasut wrote: On Monday, March 17, 2014 at 04:53:12 PM, chandramouli narayanan wrote: On Fri, 2014-03-14 at 06:40 +0100, Marek Vasut wrote: On Wednesday, March 12, 2014 at 07:47:50 PM, chandramouli narayanan wrote: This git patch adds the glue, build and configuration changes to include x86_64 AVX2 optimization of SHA1 transform to crypto support. The patch has been tested with 3.14.0-rc1 kernel. Changes from the initial version of this patch are in a) check for BMI2 in addition to AVX2 support since __sha1_transform_avx2() uses rorx b) Since the module build has dependency on 64bit, it is redundant to check it in the code here. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, tcrypt shows AVX2 performance improvement from 3% for 256 bytes update to 16% for 1024 bytes update over AVX implementation. Signed-off-by: Chandramouli Narayanan mo...@linux.intel.com diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile index 6ba54d6..61d6e28 100644 --- a/arch/x86/crypto/Makefile +++ b/arch/x86/crypto/Makefile @@ -79,6 +79,9 @@ aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o fpu.o aesni-intel-$(CONFIG_64BIT) += aesni-intel_avx-x86_64.o ghash-clmulni-intel-y := ghash-clmulni-intel_asm.o ghash-clmulni-intel_glue.o sha1-ssse3-y := sha1_ssse3_asm.o sha1_ssse3_glue.o +ifeq ($(avx2_supported),yes) +sha1-ssse3-y += sha1_avx2_x86_64_asm.o Use: sha1-ssse3-$(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o And you will not need the CONFIG_AS_AVX2 ifdef in your previous patch, no ? [...] Best regards, Marek Vasut Sorry for the delayed reply. Agreed, I will fix the dependency. No problem, thanks! Best regards, Marek Vasut On second thoughts, with sha1-sse3-(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o, I have build issues and sha1_transform_avx2 undefined in sha1-sss3.ko. I can rid #ifdef CONFIG_AS_AVX2 in patch1. The following works though: ifeq ($(avx2_supported),yes) sha1-ssse3-y += sha1_avx2_x86_64_asm.o endif thanks - mouli -- 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 2/2] SHA1 transform: x86_64 AVX2 optimization - glue build-v2
On 03/17/2014 09:53 AM, chandramouli narayanan wrote: On second thoughts, with sha1-sse3-(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o, I have build issues and sha1_transform_avx2 undefined in sha1-sss3.ko. I can rid #ifdef CONFIG_AS_AVX2 in patch1. The following works though: ifeq ($(avx2_supported),yes) sha1-ssse3-y += sha1_avx2_x86_64_asm.o endif Yes, the sad thing is that the CONFIG_AS_* things aren't real config symbols, despite the name. They might be in the future when Kconfig can run test probes (something we have needed for a very long time.) The yes versus y, though, is a total faceplant. -hpa -- 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 2/2] SHA1 transform: x86_64 AVX2 optimization - glue build-v2
On Monday, March 17, 2014 at 05:53:52 PM, chandramouli narayanan wrote: On Mon, 2014-03-17 at 17:06 +0100, Marek Vasut wrote: On Monday, March 17, 2014 at 04:53:12 PM, chandramouli narayanan wrote: On Fri, 2014-03-14 at 06:40 +0100, Marek Vasut wrote: On Wednesday, March 12, 2014 at 07:47:50 PM, chandramouli narayanan wrote: This git patch adds the glue, build and configuration changes to include x86_64 AVX2 optimization of SHA1 transform to crypto support. The patch has been tested with 3.14.0-rc1 kernel. Changes from the initial version of this patch are in a) check for BMI2 in addition to AVX2 support since __sha1_transform_avx2() uses rorx b) Since the module build has dependency on 64bit, it is redundant to check it in the code here. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, tcrypt shows AVX2 performance improvement from 3% for 256 bytes update to 16% for 1024 bytes update over AVX implementation. Signed-off-by: Chandramouli Narayanan mo...@linux.intel.com diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile index 6ba54d6..61d6e28 100644 --- a/arch/x86/crypto/Makefile +++ b/arch/x86/crypto/Makefile @@ -79,6 +79,9 @@ aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o fpu.o aesni-intel-$(CONFIG_64BIT) += aesni-intel_avx-x86_64.o ghash-clmulni-intel-y := ghash-clmulni-intel_asm.o ghash-clmulni-intel_glue.o sha1-ssse3-y := sha1_ssse3_asm.o sha1_ssse3_glue.o +ifeq ($(avx2_supported),yes) +sha1-ssse3-y += sha1_avx2_x86_64_asm.o Use: sha1-ssse3-$(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o And you will not need the CONFIG_AS_AVX2 ifdef in your previous patch, no ? [...] Best regards, Marek Vasut Sorry for the delayed reply. Agreed, I will fix the dependency. No problem, thanks! Best regards, Marek Vasut On second thoughts, with sha1-sse3-(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o, I have build issues and sha1_transform_avx2 undefined in sha1-sss3.ko. I can rid #ifdef CONFIG_AS_AVX2 in patch1. The following works though: ifeq ($(avx2_supported),yes) sha1-ssse3-y += sha1_avx2_x86_64_asm.o endif Looking throughout the arch/x86/crypto/Makefile , this sha1-ssse3.o thing is a bit odd I think. Why exactly does this not follow suit with the camellia or serpent ciphers ? I mean, look at their build rules, they handle all of SSE2/AVX/AVX2 implementation and it's build. Can we not clean up the SHA1-SSSE3 to do exactly the same ? But please note I might be just plain wrong and if that's the case, let me know ;-) btw. I noticed another nit in the code. You use __sha1_transform_avx2() , but there previous function using AVX1 is called sha1_transform_avx() . Drop those two underscores please for consistency's sake. Thanks! 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: [PATCH cryptodev 3/4] crypto: testmgr - add aead null encryption test vectors
On Friday, March 14, 2014 at 04:46:51 PM, Horia Geanta wrote:
Add test vectors for aead with null encryption and md5,
respectively sha1 authentication.
Input data is taken from test vectors listed in RFC2410.
Signed-off-by: Horia Geanta horia.gea...@freescale.com
[...]
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -12821,6 +12821,10 @@ static struct cipher_testvec
cast6_xts_dec_tv_template[] = { #define AES_DEC_TEST_VECTORS 4
#define AES_CBC_ENC_TEST_VECTORS 5
#define AES_CBC_DEC_TEST_VECTORS 5
+#define HMAC_MD5_ECB_CIPHER_NULL_ENC_TEST_VECTORS 2
+#define HMAC_MD5_ECB_CIPHER_NULL_DEC_TEST_VECTORS 2
+#define HMAC_SHA1_ECB_CIPHER_NULL_ENC_TEST_VECTORS 2
+#define HMAC_SHA1_ECB_CIPHER_NULL_DEC_TEST_VECTORS 2
#define HMAC_SHA1_AES_CBC_ENC_TEST_VECTORS 7
#define HMAC_SHA256_AES_CBC_ENC_TEST_VECTORS 7
#define HMAC_SHA512_AES_CBC_ENC_TEST_VECTORS 7
@@ -13627,6 +13631,90 @@ static struct cipher_testvec
aes_cbc_dec_tv_template[] = { },
};
+static struct aead_testvec hmac_md5_ecb_cipher_null_enc_tv_template[] = {
+ { /* Input data from RFC 2410 Case 1 */
+#ifdef __LITTLE_ENDIAN
+ .key= \x08\x00/* rta length */
+ \x01\x00/* rta type */
+#else
+ .key= \x00\x08/* rta length */
+ \x00\x01/* rta type */
+#endif
This endianness thing looks a bit unhealthy. Is this really needed or is this a
hack for some driver casting this field to u32 and then accessing it as such ?
+ \x00\x00\x00\x00/* enc key length */
+ \x00\x00\x00\x00\x00\x00\x00\x00
+ \x00\x00\x00\x00\x00\x00\x00\x00,
+ .klen = 8 + 16 + 0,
+ .iv = ,
+ .input = \x01\x23\x45\x67\x89\xab\xcd\xef,
+ .ilen = 8,
+ .result = \x01\x23\x45\x67\x89\xab\xcd\xef
+ \xaa\x42\xfe\x43\x8d\xea\xa3\x5a
+ \xb9\x3d\x9f\xb1\xa3\x8e\x9b\xae,
+ .rlen = 8 + 16,
[...]
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: [PATCH] arm64/lib: add optimized implementation of sha_transform
On Friday, March 14, 2014 at 04:02:33 PM, Ard Biesheuvel wrote: This implementation keeps the 64 bytes of workspace in registers rather than on the stack, eliminating most of the loads and stores, and reducing the instruction count by about 25%. Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- Hello all, No performance numbers I am allowed to share, unfortunately, so if anyone else (with access to actual, representative hardware) would care to have a go, I would be very grateful. This can be done by building the tcrypt.ko module (CONFIG_CRYPTO_TEST=m), and inserting the module using 'mode=303' as a parameter (note that the insmod always fails, but produces its test output to the kernel log). Also note that the sha_transform() function will be part of the kernel proper, so just rebuilding the sha1_generic module is not sufficient. Cheers, Won't the function sha_transform() collide with the one in lib/sha1.c ? Or will the one in lib/sha1.c be overriden somehow ? Otherwise: Reviewed-by: Marek Vasut ma...@denx.de 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: [PATCH cryptodev 1/4] crypto: caam - remove error propagation handling
On Friday, March 14, 2014 at 04:46:49 PM, Horia Geanta wrote: Commit 61bb86bba169507a5f223b94b9176c32c84b4721 (crypto: caam - set descriptor sharing type to SERIAL) changed the descriptor sharing mode from SHARE_WAIT to SHARE_SERIAL. All descriptor commands that handle the ok to share and error propagation settings should also go away, since they have no meaning for SHARE_SERIAL. [...] @@ -253,7 +236,7 @@ static int aead_set_sh_desc(struct crypto_aead *aead) /* assoclen + cryptlen = seqinlen - ivsize */ append_math_sub_imm_u32(desc, REG2, SEQINLEN, IMM, tfm-ivsize); - /* assoclen + cryptlen = (assoclen + cryptlen) - cryptlen */ + /* assoclen = (assoclen + cryptlen) - cryptlen */ This comment basically says 'x = x' , but it doesn't explain anything to uninformed observer. Can you fix such comments please ? [...] 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: [PATCH 2/2] SHA1 transform: x86_64 AVX2 optimization - glue build-v2
On Mon, 2014-03-17 at 19:11 +0100, Marek Vasut wrote: On Monday, March 17, 2014 at 05:53:52 PM, chandramouli narayanan wrote: On Mon, 2014-03-17 at 17:06 +0100, Marek Vasut wrote: On Monday, March 17, 2014 at 04:53:12 PM, chandramouli narayanan wrote: On Fri, 2014-03-14 at 06:40 +0100, Marek Vasut wrote: On Wednesday, March 12, 2014 at 07:47:50 PM, chandramouli narayanan wrote: This git patch adds the glue, build and configuration changes to include x86_64 AVX2 optimization of SHA1 transform to crypto support. The patch has been tested with 3.14.0-rc1 kernel. Changes from the initial version of this patch are in a) check for BMI2 in addition to AVX2 support since __sha1_transform_avx2() uses rorx b) Since the module build has dependency on 64bit, it is redundant to check it in the code here. On a Haswell desktop, with turbo disabled and all cpus running at maximum frequency, tcrypt shows AVX2 performance improvement from 3% for 256 bytes update to 16% for 1024 bytes update over AVX implementation. Signed-off-by: Chandramouli Narayanan mo...@linux.intel.com diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile index 6ba54d6..61d6e28 100644 --- a/arch/x86/crypto/Makefile +++ b/arch/x86/crypto/Makefile @@ -79,6 +79,9 @@ aesni-intel-y := aesni-intel_asm.o aesni-intel_glue.o fpu.o aesni-intel-$(CONFIG_64BIT) += aesni-intel_avx-x86_64.o ghash-clmulni-intel-y := ghash-clmulni-intel_asm.o ghash-clmulni-intel_glue.o sha1-ssse3-y := sha1_ssse3_asm.o sha1_ssse3_glue.o +ifeq ($(avx2_supported),yes) +sha1-ssse3-y += sha1_avx2_x86_64_asm.o Use: sha1-ssse3-$(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o And you will not need the CONFIG_AS_AVX2 ifdef in your previous patch, no ? [...] Best regards, Marek Vasut Sorry for the delayed reply. Agreed, I will fix the dependency. No problem, thanks! Best regards, Marek Vasut On second thoughts, with sha1-sse3-(CONFIG_AS_AVX2) += sha1_avx2_x86_64_asm.o, I have build issues and sha1_transform_avx2 undefined in sha1-sss3.ko. I can rid #ifdef CONFIG_AS_AVX2 in patch1. The following works though: ifeq ($(avx2_supported),yes) sha1-ssse3-y += sha1_avx2_x86_64_asm.o endif Looking throughout the arch/x86/crypto/Makefile , this sha1-ssse3.o thing is a bit odd I think. Why exactly does this not follow suit with the camellia or serpent ciphers ? I mean, look at their build rules, they handle all of SSE2/AVX/AVX2 implementation and it's build. Can we not clean up the SHA1-SSSE3 to do exactly the same ? But please note I might be just plain wrong and if that's the case, let me know ;-) I appended AVX2 support to the existing sha1_ssse3_glue. I will see if it can be cleaned up. btw. I noticed another nit in the code. You use __sha1_transform_avx2() , but there previous function using AVX1 is called sha1_transform_avx() . Drop those two underscores please for consistency's sake. __sha1_transform_avx2() is merely an internal inline function. The code patch picks sha1_transform_avx() or sha1_transform_avx2() depending on the datablock size (based on the results from running tcrypt). Thanks! Best regards, Marek Vasut thanks - mouli -- 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 PATCH 03/22] staging: crypto: skein: allow building statically
On Tue, Mar 11, 2014 at 09:32:35PM +, Jason Cooper wrote: These are the minimum changes required to get the code to build statically in the kernel. It's necessary to do this first so that we can empirically determine that future cleanup patches aren't changing the generated object code. Signed-off-by: Jason Cooper ja...@lakedaemon.net This doesn't apply to my latest tree :( --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -65,3 +65,4 @@ obj-$(CONFIG_XILLYBUS) += xillybus/ obj-$(CONFIG_DGNC) += dgnc/ obj-$(CONFIG_DGAP) += dgap/ obj-$(CONFIG_MTD_SPINAND_MT29F) += mt29f_spinand/ +obj-$(CONFIG_CRYPTO_SKEIN) += skein/ Care to align these up with the way this file is formatted? And I have no objection to taking the drivers/staging/ patches, the script looks useful, but I can't take it through the staging tree, sorry. thanks, greg k-h -- 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] Fix late crypto work queue initialization
The crypto algorithm modules utilizing the crypto daemon could be used early when the system start up. Using module_init does not guarantee that the daemon's work queue is initialized when the cypto alorithm depending on crypto_wq starts. It is necessary to initialize the crypto work queue earlier at the subsystem init time to make sure that it is initialized when used. Signed-off-by: Tim Chen tim.c.c...@linux.intel.com --- crypto/crypto_wq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/crypto_wq.c b/crypto/crypto_wq.c index adad92a..2f1b8d1 100644 --- a/crypto/crypto_wq.c +++ b/crypto/crypto_wq.c @@ -33,7 +33,7 @@ static void __exit crypto_wq_exit(void) destroy_workqueue(kcrypto_wq); } -module_init(crypto_wq_init); +subsys_initcall(crypto_wq_init); module_exit(crypto_wq_exit); MODULE_LICENSE(GPL); -- 1.7.11.7 -- 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
