Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Dienstag, 27. Oktober 2015, 18:19:01 schrieb David Woodhouse: Hi David, > >That's largely orthogonal to the point Marcel was making. > >The point is that akcipher is limited to using keys for which we have >the private key material available directly in software. We cannot Agreed. >expose that critically limited API to userspace. We need to expose an >API which supports hardware keys, and basically that means using the >kernel's key subsystem. Agreed. But at the same time, that interface should be able to support the use case where the software wants to be in control (just take OpenSSL as the simple example where you can add an engine for the Linux kernel backed RSA operation). Note, the goal with AF_ALG is simply to expose asymmetric hardware support to user space for unspecified use cases to make user space faster. > >For a key which *happens* to be in software, the key subsystem may end >up *using* akcipher behind the scenes. But the API we expose to >userspace cannot simply be based on akcipher. So, how do you propose that would work? Based on what I understand the suggested logic flow for a simple OpenSSL-like approach would be: 1. OpenSSL opens the interface with the kernel key subsystem and sends the pub/priv key along 2. the key subsystem hooks the key in 3. the key subsystem sees that there is a simple RSA operation to be made 4. the key subsystem initiates an akcipher operation and sends the keys along 5. the akcipher returns the cipher result to the key subsystem 6. the key subsystem sends the data to user space Currently I fail to understand why that key subsystem would help me in that common use case (note, I totally understand to use the key subsystem when you have some key management schema in place). Also, I fail to see that this logic flow would be fast to warrant a detour from user land into kernel land for an RSA operation. Thanks Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Dienstag, 27. Oktober 2015, 13:54:30 schrieb Marcel Holtmann: Hi Marcel, >Hi Stephan, > >> This patch set adds the AF_ALG user space API to externalize the >> asymmetric cipher API recently added to the kernel crypto API. >> >> The patch set is tested with the user space library of libkcapi [1]. >> Use [1] test/test.sh for a full test run. The test covers the >> >> following scenarios: >> * sendmsg of one IOVEC >> >> * sendmsg of 16 IOVECs with non-linear buffer >> >> * vmsplice of one IOVEC >> >> * vmsplice of 15 IOVECs with non-linear buffer >> >> * invoking multiple separate cipher operations with one >> >>open cipher handle >> >> * encryption with private key (using vector from testmgr.h) >> >> * encryption with public key (using vector from testmgr.h) >> >> * decryption with private key (using vector from testmgr.h) > >after having discussions with David Howells and David Woodhouse, I don't >think we should expose akcipher via AF_ALG at all. I think the akcipher >operations for sign/verify/encrypt/decrypt should operate on asymmetric keys >in the first place. With akcipher you are pretty much bound to public and >private keys and the key is the important part and not the akcipher itself. >Especially since we want to support private keys in hardware (like TPM for >example). > >It seems more appropriate to use keyctl to derive the symmetric session key Are you saying that you consider importing parts of TLS into the kernel? Considering the use case where akcipher would be used to speed up network protocols, I would imply that your comment refers to importing parts of that network protocol into the kernel. The key derivation that you mention here would be: RSA-based key exchange plus the TLS KDF. Do we really want to load that into the kernel given that TLS is one protocol and there are many others? >from your asymmetric key. And then use the symmetric session key id with >skcipher via AF_ALG. Especially once symmetric key type has been introduced >this seems to be trivial then. > >I am not really in favor of having two userspace facing APIs for asymmetric >cipher usage. And we need to have an API that is capable to work with >hardware keys. > >Regards > >Marcel > >-- >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 Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] crypto: akcipher: fix typos in include/crypto/akcipher.h
Am Dienstag, 20. Oktober 2015, 09:34:01 schrieb LABBE Corentin:
Hi LABBE,
>Fix numerous spelling error in include/crypto/akcipher.h
>
>Signed-off-by: LABBE Corentin
>---
> include/crypto/akcipher.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
>diff --git a/include/crypto/akcipher.h b/include/crypto/akcipher.h
>index 69d163e..0c9fa68 100644
>--- a/include/crypto/akcipher.h
>+++ b/include/crypto/akcipher.h
>@@ -19,12 +19,12 @@
> *
> * @base: Common attributes for async crypto requests
> * @src: Pointer to memory containing the input parameters
>- *The format of the parameter(s) is expeted to be Octet String
>- * @dst: Pointer to memory whare the result will be stored
>+ *The format of the parameter(s) is expected to be Octet String
>+ * @dst: Pointer to memory where the result will be stored
> * @src_len: Size of the input parameter
>- * @dst_len: Size of the output buffer. It needs to be at leaset
>+ * @dst_len: Size of the output buffer. It needs to be at least
> *as big as the expected result depending on the operation
>- *After operation it will be updated with the acctual size of
the
>+ *After operation it will be updated with the actual size of the
> *result. In case of error, where the dst_len was insufficient,
> *it will be updated to the size required for the operation.
> * @__ctx:Start of private context data
>@@ -59,7 +59,7 @@ struct crypto_akcipher {
> *algorithm. In case of error, where the dst_len was
insufficient,
> *the req->dst_len will be updated to the size required for the
> *operation
>- * @encrypt: Function performs an encrytp operation as defined by public
key
>+ * @encrypt: Function performs an encrypt operation as defined by public
>key * algorithm. In case of error, where the dst_len was
insufficient,
>* the req->dst_len will be updated to the size required for the
> *operation
>@@ -224,7 +224,7 @@ static inline void akcipher_request_set_callback(struct
>akcipher_request *req, }
>
> /**
>- * akcipher_request_set_crypt() -- Sets reqest parameters
>+ * akcipher_request_set_crypt() -- Sets request parameters
Note, this patch will clash with my patch that I sent 2 days ago: I removed
the double slashes from these lines here as they do not look good in a
DocBook.
> *
> * Sets parameters required by crypto operation
> *
>@@ -233,7 +233,7 @@ static inline void akcipher_request_set_callback(struct
>akcipher_request *req, * @dst: ptr of output parameter
> * @src_len: size of the input buffer
> * @dst_len: size of the output buffer. It will be updated by the
>- *implementation to reflect the acctual size of the result
>+ *implementation to reflect the actual size of the result
> */
> static inline void akcipher_request_set_crypt(struct akcipher_request *req,
> void *src, void *dst,
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Montag, 19. Oktober 2015, 09:32:30 schrieb Herbert Xu: Hi Herbert, > On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote: > > Hi, > > > > This patch set adds the AF_ALG user space API to externalize the > > asymmetric cipher API recently added to the kernel crypto API. > > > > The patch set is tested with the user space library of libkcapi [1]. > > Use [1] test/test.sh for a full test run. The test covers the > > > following scenarios: > Thanks Stephan. But I would prefer to defer this til after we have > completed the conversion of current in-kernel users. This is because > changing the kernel interface is easy while changing the user-space > interface is not. Sure, let us wait. However, I would suggest that you pull patch 1/5 as this is a bug fix that may affect even other users. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] crypto: AF_ALG -- add setpubkey setsockopt call
For supporting asymmetric ciphers, user space must be able to set the
public key. The patch adds a new setsockopt call for setting the public
key.
Signed-off-by: Stephan Mueller
---
crypto/af_alg.c | 14 +++---
include/crypto/if_alg.h | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index a8e7aa3..bf6528e 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -173,13 +173,16 @@ static int alg_bind(struct socket *sock, struct sockaddr
*uaddr, int addr_len)
}
static int alg_setkey(struct sock *sk, char __user *ukey,
- unsigned int keylen)
+ unsigned int keylen, bool pubkey)
{
struct alg_sock *ask = alg_sk(sk);
const struct af_alg_type *type = ask->type;
u8 *key;
int err;
+ if (pubkey && !type->setpubkey)
+ return -EOPNOTSUPP;
+
key = sock_kmalloc(sk, keylen, GFP_KERNEL);
if (!key)
return -ENOMEM;
@@ -188,7 +191,10 @@ static int alg_setkey(struct sock *sk, char __user *ukey,
if (copy_from_user(key, ukey, keylen))
goto out;
- err = type->setkey(ask->private, key, keylen);
+ if (pubkey)
+ err = type->setpubkey(ask->private, key, keylen);
+ else
+ err = type->setkey(ask->private, key, keylen);
out:
sock_kzfree_s(sk, key, keylen);
@@ -212,12 +218,14 @@ static int alg_setsockopt(struct socket *sock, int level,
int optname,
switch (optname) {
case ALG_SET_KEY:
+ case ALG_SET_PUBKEY:
if (sock->state == SS_CONNECTED)
goto unlock;
if (!type->setkey)
goto unlock;
- err = alg_setkey(sk, optval, optlen);
+ err = alg_setkey(sk, optval, optlen,
+(optname == ALG_SET_PUBKEY) ? true : false);
break;
case ALG_SET_AEAD_AUTHSIZE:
if (sock->state == SS_CONNECTED)
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 018afb2..ca4dc72 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -49,6 +49,7 @@ struct af_alg_type {
void *(*bind)(const char *name, u32 type, u32 mask);
void (*release)(void *private);
int (*setkey)(void *private, const u8 *key, unsigned int keylen);
+ int (*setpubkey)(void *private, const u8 *key, unsigned int keylen);
int (*accept)(void *private, struct sock *sk);
int (*setauthsize)(void *private, unsigned int authsize);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] crypto: AF_ALG -- add sign/verify API
Add the flags for handling signature generation and signature
verification.
Also, the patch adds the interface for setting a public key.
Signed-off-by: Stephan Mueller
---
include/uapi/linux/if_alg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index f2acd2f..02e6162 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -34,9 +34,12 @@ struct af_alg_iv {
#define ALG_SET_OP 3
#define ALG_SET_AEAD_ASSOCLEN 4
#define ALG_SET_AEAD_AUTHSIZE 5
+#define ALG_SET_PUBKEY 6
/* Operations */
#define ALG_OP_DECRYPT 0
#define ALG_OP_ENCRYPT 1
+#define ALG_OP_SIGN2
+#define ALG_OP_VERIFY 3
#endif /* _LINUX_IF_ALG_H */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/5] crypto: add algif_akcipher user space API
Hi, This patch set adds the AF_ALG user space API to externalize the asymmetric cipher API recently added to the kernel crypto API. The patch set is tested with the user space library of libkcapi [1]. Use [1] test/test.sh for a full test run. The test covers the following scenarios: * sendmsg of one IOVEC * sendmsg of 16 IOVECs with non-linear buffer * vmsplice of one IOVEC * vmsplice of 15 IOVECs with non-linear buffer * invoking multiple separate cipher operations with one open cipher handle * encryption with private key (using vector from testmgr.h) * encryption with public key (using vector from testmgr.h) * decryption with private key (using vector from testmgr.h) The patch set includes a fix for the MPI parsing that is visible when using SGL members that contain one byte. Changes v2: * use updated SGL-based akcipher API * allow mix-n-match of sendmsg and vmsplice calls [1] http://www.chronox.de/libkcapi.html Stephan Mueller (5): MPI: fix off by one in mpi_read_raw_from_sgl crypto: AF_ALG -- add sign/verify API crypto: AF_ALG -- add setpubkey setsockopt call crypto: AF_ALG -- add asymmetric cipher interface crypto: algif_akcipher - enable compilation crypto/Kconfig | 9 + crypto/Makefile | 1 + crypto/af_alg.c | 14 +- crypto/algif_akcipher.c | 542 include/crypto/if_alg.h | 1 + include/uapi/linux/if_alg.h | 3 + lib/mpi/mpicoder.c | 5 +- 7 files changed, 571 insertions(+), 4 deletions(-) create mode 100644 crypto/algif_akcipher.c -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/5] crypto: algif_akcipher - enable compilation
Add the Makefile and Kconfig updates to allow algif_akcipher to be compiled. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 9 + crypto/Makefile | 1 + 2 files changed, 10 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index fc93444..aa5d3aa 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1632,6 +1632,15 @@ config CRYPTO_USER_API_AEAD This option enables the user-spaces interface for AEAD cipher algorithms. +config CRYPTO_USER_API_AKCIPHER + tristate "User-space interface for asymmetric key cipher algorithms" + depends on NET + select CRYPTO_AKCIPHER2 + select CRYPTO_USER_API + help + This option enables the user-spaces interface for asymmetric + key cipher algorithms. + config CRYPTO_HASH_INFO bool diff --git a/crypto/Makefile b/crypto/Makefile index d897e0b..3aaa914 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -120,6 +120,7 @@ obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o +obj-$(CONFIG_CRYPTO_USER_API_AKCIPHER) += algif_akcipher.o # # generic algorithms and the async_tx api -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] crypto: AF_ALG -- add asymmetric cipher interface
This patch adds the user space interface for asymmetric ciphers. The
interface allows the use of sendmsg as well as vmsplice to provide data.
Signed-off-by: Stephan Mueller
---
crypto/algif_akcipher.c | 542
1 file changed, 542 insertions(+)
create mode 100644 crypto/algif_akcipher.c
diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
new file mode 100644
index 000..7c58e9b
--- /dev/null
+++ b/crypto/algif_akcipher.c
@@ -0,0 +1,542 @@
+/*
+ * algif_akcipher: User-space interface for asymmetric cipher algorithms
+ *
+ * Copyright (C) 2015, Stephan Mueller
+ *
+ * This file provides the user-space API for asymmetric ciphers.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct akcipher_sg_list {
+ unsigned int cur;
+ struct scatterlist sg[ALG_MAX_PAGES];
+};
+
+struct akcipher_ctx {
+ struct akcipher_sg_list tsgl;
+ struct af_alg_sgl rsgl[ALG_MAX_PAGES];
+
+ struct af_alg_completion completion;
+
+ unsigned long used;
+
+ unsigned int len;
+ bool more;
+ bool merge;
+ int op;
+
+ struct akcipher_request req;
+};
+
+static inline int akcipher_sndbuf(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+
+ return max_t(int, max_t(int, sk->sk_sndbuf & PAGE_MASK, PAGE_SIZE) -
+ ctx->used, 0);
+}
+
+static inline bool akcipher_writable(struct sock *sk)
+{
+ return PAGE_SIZE <= akcipher_sndbuf(sk);
+}
+
+static inline int akcipher_calcsize(struct akcipher_ctx *ctx)
+{
+ return crypto_akcipher_maxsize(crypto_akcipher_reqtfm(&ctx->req));
+}
+
+static void akcipher_put_sgl(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+ struct akcipher_sg_list *sgl = &ctx->tsgl;
+ struct scatterlist *sg = sgl->sg;
+ unsigned int i;
+
+ for (i = 0; i < sgl->cur; i++) {
+ if (!sg_page(sg + i))
+ continue;
+
+ put_page(sg_page(sg + i));
+ sg_assign_page(sg + i, NULL);
+ }
+ sg_init_table(sg, ALG_MAX_PAGES);
+ sgl->cur = 0;
+ ctx->used = 0;
+ ctx->more = 0;
+ ctx->merge = 0;
+}
+
+static void akcipher_wmem_wakeup(struct sock *sk)
+{
+ struct socket_wq *wq;
+
+ if (!akcipher_writable(sk))
+ return;
+
+ rcu_read_lock();
+ wq = rcu_dereference(sk->sk_wq);
+ if (wq_has_sleeper(wq))
+ wake_up_interruptible_sync_poll(&wq->wait, POLLIN |
+ POLLRDNORM |
+ POLLRDBAND);
+ sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
+ rcu_read_unlock();
+}
+
+static int akcipher_wait_for_data(struct sock *sk, unsigned flags)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+ long timeout;
+ DEFINE_WAIT(wait);
+ int err = -ERESTARTSYS;
+
+ if (flags & MSG_DONTWAIT)
+ return -EAGAIN;
+
+ set_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+ for (;;) {
+ if (signal_pending(current))
+ break;
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+ timeout = MAX_SCHEDULE_TIMEOUT;
+ if (sk_wait_event(sk, &timeout, !ctx->more)) {
+ err = 0;
+ break;
+ }
+ }
+ finish_wait(sk_sleep(sk), &wait);
+
+ clear_bit(SOCK_ASYNC_WAITDATA, &sk->sk_socket->flags);
+
+ return err;
+}
+
+static void akcipher_data_wakeup(struct sock *sk)
+{
+ struct alg_sock *ask = alg_sk(sk);
+ struct akcipher_ctx *ctx = ask->private;
+ struct socket_wq *wq;
+
+ if (ctx->more)
+ return;
+ if (!ctx->used)
+ return;
+
+ rcu_read_lock();
+ wq = rcu_dereference(sk->sk_wq);
+ if (wq_has_sleeper(wq))
+ wake_up_interruptible_sync_poll(&wq->wait, POLLOUT |
+ POLLRDNORM |
+ POLLRDBAND);
+ sk_wake_async(sk, SOCK_WAKE_SPACE, POLL_OUT);
+ rcu_read_unlock();
+}
+
+static int akcipher_sendmsg(struct socket *sock, struct msghdr *msg,
+ size_t size)
+{
+ struct so
[PATCH v2 1/5] MPI: fix off by one in mpi_read_raw_from_sgl
The patch fixes the analysis of the input data which contains an off
by one.
The issue is visible when the SGL contains one byte per SG entry.
The code for checking for zero bytes does not operate on the data byte.
Signed-off-by: Stephan Mueller
---
lib/mpi/mpicoder.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
index c20ef27..c7e0a70 100644
--- a/lib/mpi/mpicoder.c
+++ b/lib/mpi/mpicoder.c
@@ -446,8 +446,11 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl,
unsigned int len)
const u8 *buff = sg_virt(sg);
int len = sg->length;
- while (len-- && !*buff++)
+ while (len && !*buff) {
lzeros++;
+ len--;
+ buff++;
+ }
if (len && *buff)
break;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256
Am Freitag, 11. September 2015, 11:49:32 schrieb Tim Chen: Hi Tim, >On Fri, 2015-09-11 at 19:02 +0200, Stephan Mueller wrote: >> Am Donnerstag, 10. September 2015, 17:04:31 schrieb Tim Chen: >> >> Hi Tim, >> >> >Is there a scenario you can think of >> >when a lower performing sha1 transform needs to >> >be exposed as a separate driver? >> >> My immediate concern is testing: it is hard to test the individual >> implementations. > >Not hard, just one line in the glue code to set the transform >to the one you need it you really want to test individual >implementation. Usually user of sha don't care which sha driver >they got, but just the highest priority one. >So you will anyway need to patch and change the priority of the sha >driver to expose a specific one for testing. Sure, it is not hard when you recompile. But when you have to test one given kernel binary, it is a challenge. > >> >Otherwise the glue code logic will only expose the >> >best performing one for a cpu and hide the others, which was intentional >> >on our part to prevent a lower performing sha from getting used. >> >> Agreed, but the kernel crypto API does that already using the priorities -- >> IMHO a very clean and easy to interpret solution. >> >> Furthermore, if somebody really has a need to not use the fastest HW >> implementation, the kernel crypto API allows him to do that. With the hard- >> wired approach in the glue file, you are stuck. > >Still, why would some kernel module specifically not want to >use the fastest HW implementation, and explicitly ask for >a slower driver? I have seen one instance where a hardware driver was broken on one particular hardware. So, the only way was to disable it. In our case here, disabling means to go back to the software implementation of SHA. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256
Am Donnerstag, 10. September 2015, 17:04:31 schrieb Tim Chen: Hi Tim, > >Is there a scenario you can think of >when a lower performing sha1 transform needs to >be exposed as a separate driver? My immediate concern is testing: it is hard to test the individual implementations. > >Otherwise the glue code logic will only expose the >best performing one for a cpu and hide the others, which was intentional >on our part to prevent a lower performing sha from getting used. Agreed, but the kernel crypto API does that already using the priorities -- IMHO a very clean and easy to interpret solution. Furthermore, if somebody really has a need to not use the fastest HW implementation, the kernel crypto API allows him to do that. With the hard- wired approach in the glue file, you are stuck. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] crypto: [sha] glue code for Intel SHA extensions optimized SHA1 & SHA256
Am Donnerstag, 10. September 2015, 15:27:20 schrieb Tim Chen: Hi Tim, >This patch adds the glue code to detect and utilize the Intel SHA >extensions optimized SHA1 and SHA256 update transforms when available. > >This code has been tested on Broxton for functionality. A general comment on this file: shouldn't this file be cleaned and use the standard mechanisms of the kernel crypto API? This glue implements its own selection of which SHA implementation to use. But the kernel crypto API implements that logic already. The issue with the current implementation in this file is that you have no clue which particular implementation of SHA is in use in one particular case. So, may I suggest a restructuring to define independent instances of SHA, such as - cra_name == "sha1", cra_driver_name="sha1_ssse3", cra_priority=300 - cra_name == "sha1", cra_driver_name="sha1_avx", cra_priority=400 - cra_name == "sha1", cra_driver_name="sha1_avx2", cra_priority=500 - cra_name == "sha1", cra_driver_name="sha1_shavx", cra_priority=600 Similarly for the other SHAs? In all the register functions for the ciphers, you can bail out if the hardware does not support an implementation. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] crypto: testmgr: test IV value after a cipher operation
Am Dienstag, 16. Juni 2015, 11:46:46 schrieb Boris Brezillon:
Hi Herbert,
>The crypto drivers are supposed to update the IV passed to the crypto
>request before calling the completion callback.
>Test for the IV value before considering the test as successful.
May I ask whether there is anything wrong with this patch?
I am asking because the keywrapping template I would like to release would
need the test manager to check the generated IV.
Thanks a lot.
>
>Signed-off-by: Boris Brezillon
>---
> crypto/testmgr.c | 12 +++-
> crypto/testmgr.h | 1 +
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
>diff --git a/crypto/testmgr.c b/crypto/testmgr.c
>index f9bce3d..e6b5f24 100644
>--- a/crypto/testmgr.c
>+++ b/crypto/testmgr.c
>@@ -1013,12 +1013,22 @@ static int __test_skcipher(struct crypto_ablkcipher
>*tfm, int enc,
>
> q = data;
> if (memcmp(q, template[i].result, template[i].rlen)) {
>- pr_err("alg: skcipher%s: Test %d failed on %s for
%s\n",
>+ pr_err("alg: skcipher%s: Test %d failed (invalid
result) on %s for %s\n",
>d, j, e, algo);
> hexdump(q, template[i].rlen);
> ret = -EINVAL;
> goto out;
> }
>+
>+ if (template[i].iv_out &&
>+ memcmp(iv, template[i].iv_out,
>+ crypto_ablkcipher_ivsize(tfm))) {
>+ pr_err("alg: skcipher%s: Test %d failed (invalid
output IV) on %s for
>%s\n", + d, j, e, algo);
>+ hexdump(iv, crypto_ablkcipher_ivsize(tfm));
>+ ret = -EINVAL;
>+ goto out;
>+ }
> }
>
> j = 0;
>diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>index 62e2485..03320f9 100644
>--- a/crypto/testmgr.h
>+++ b/crypto/testmgr.h
>@@ -49,6 +49,7 @@ struct hash_testvec {
> struct cipher_testvec {
> char *key;
> char *iv;
>+ char *iv_out;
> char *input;
> char *result;
> unsigned short tap[MAX_TAP];
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] crypto: KEYS: convert public key to the akcipher API
Am Mittwoch, 12. August 2015, 20:54:39 schrieb Tadeusz Struk:
Hi Tadeusz,
>@@ -41,7 +41,7 @@ struct pkcs7_parse_context {
> static void pkcs7_free_signed_info(struct pkcs7_signed_info *sinfo)
> {
> if (sinfo) {
>- mpi_free(sinfo->sig.mpi[0]);
>+ kfree(sinfo->sig.s);
kzfree?
> kfree(sinfo->sig.digest);
kzfree?
> kfree(sinfo->signing_cert_id);
> kfree(sinfo);
kzfree (due to ->msdigest)?
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: doc - make URL into hyperlink
Am Donnerstag, 6. August 2015, 14:49:00 schrieb Brian Norris: Hi Brian, >The HTML output works a little nicer that way. > >Signed-off-by: Brian Norris Thank you. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Add support for Hyperlinks and Markup on kernel-doc
Am Donnerstag, 23. Juli 2015, 15:16:23 schrieb Danilo Cesar Lemes de Paula: Hi Danilo, >This series add supports for hyperlink cross-references on Docbooks and >an optional markup syntax for in-source Documentation. Can you please give an example what you mean with the latter? Thanks for updating the documentation generation. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] jent: use safe format string parameters
Am Freitag, 24. Juli 2015, 15:41:27 schrieb Kees Cook:
Hi Kees,
>Since the API for jent_panic() does not include format string parameters,
>adjust the call to panic() to use a literal string to avoid any future
>callers from leaking format strings into the panic message.
>
>Signed-off-by: Kees Cook
Thanks.
Acked-by: Stephan Mueller
>---
> crypto/jitterentropy-kcapi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c
>index b32d834144cd..ceea83d13168 100644
>--- a/crypto/jitterentropy-kcapi.c
>+++ b/crypto/jitterentropy-kcapi.c
>@@ -79,7 +79,7 @@ int jent_fips_enabled(void)
>
> void jent_panic(char *s)
> {
>- panic(s);
>+ panic("%s", s);
> }
>
> void jent_memcpy(void *dest, const void *src, unsigned int n)
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] crypto: omap-aes: gmc: Add algo info
Am Donnerstag, 2. Juli 2015, 15:24:58 schrieb Lokesh Vutla:
Hi Lokesh,
>>> +{
>>> + .cra_name = "gcm(aes)",
>>> + .cra_driver_name= "gcm-aes-omap",
>>> + .cra_priority = 100,
>>
>> Why did you choose the priority 100? The software implementations commonly
>> use 100. crypto/gcm.c uses the prio of the underlying cipher. In case of
>> ARM, there seem to be assembler implementations of AES which have the prio
>> of 200 or 300. So, such software implementation of gcm(aes) would have a
>> higher precedence than your hw implementation.
>
>Yes, you are right.
>Other hw algos in omap-aes also uses priority 100.
>Only sw and hw implementations are enabled right now and both are at same
>priority. And till now its lucky enough that hw algo gets picked.
Maybe those HW prios should be updated too?
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] crypto: omap-aes: gmc: Add algo info
Am Donnerstag, 2. Juli 2015, 10:48:38 schrieb Lokesh Vutla:
Hi Lokesh,
>Now the driver supports gcm mode, add omap-aes-gcm
>algo info to omap-aes driver.
>
>Signed-off-by: Lokesh Vutla
>---
> drivers/crypto/omap-aes.c | 22 ++
> 1 file changed, 22 insertions(+)
>
>diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
>index e5e9a19..11f3850 100644
>--- a/drivers/crypto/omap-aes.c
>+++ b/drivers/crypto/omap-aes.c
>@@ -789,6 +789,28 @@ static struct crypto_alg algs_ctr[] = {
> .decrypt= omap_aes_ctr_decrypt,
> }
> },
>+{
>+ .cra_name = "gcm(aes)",
>+ .cra_driver_name= "gcm-aes-omap",
>+ .cra_priority = 100,
Why did you choose the priority 100? The software implementations commonly use
100. crypto/gcm.c uses the prio of the underlying cipher. In case of ARM,
there seem to be assembler implementations of AES which have the prio of 200
or 300. So, such software implementation of gcm(aes) would have a higher
precedence than your hw implementation.
So, if a user would use gcm(aes), isn't it more likely that he gets the
software implementation?
>+ .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC |
>+CRYPTO_ALG_KERN_DRIVER_ONLY,
>+ .cra_blocksize = AES_BLOCK_SIZE,
>+ .cra_ctxsize= sizeof(struct omap_aes_ctx),
>+ .cra_alignmask = 0xf,
>+ .cra_type = &crypto_aead_type,
>+ .cra_module = THIS_MODULE,
>+ .cra_init = omap_aes_gcm_cra_init,
>+ .cra_exit = omap_aes_cra_exit,
>+ .cra_u.aead = {
>+ .maxauthsize= AES_BLOCK_SIZE,
>+ .geniv = "eseqiv",
>+ .ivsize = AES_BLOCK_SIZE,
>+ .setkey = omap_aes_gcm_setkey,
>+ .encrypt= omap_aes_gcm_encrypt,
>+ .decrypt= omap_aes_gcm_decrypt,
>+ }
>+},
> };
>
> static struct omap_aes_algs_info omap_aes_algs_info_ecb_cbc[] = {
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto-jitterentropy: Delete unnecessary checks before the function call "kzfree"
Am Mittwoch, 24. Juni 2015, 10:48:19 schrieb Dan Carpenter: Hi Dan, >The other NULL assignment isn't useful either. Also If >"entropy_collector" is NULL then we would oops calling >kzfree(entropy_collector->mem); > ^^ >Dereference. > >I don't understand the patch that you sent. We shouldn't be introducing >jent_zalloc() or jent_zfree(). Why are you adding abstractions there? The one C file should have no dependencies on any kernel header files. Thus, all links to kernel functions are wrapped. >Quite bad ones as well. What would you suggest to change? Thanks. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] random: add random_initialized command line param
Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek: Hi Pavel, > On Mon 2015-05-18 18:25:25, Stephan Mueller wrote: > > Make the threshold at which the output entropy pools are considered to > > be initialized configurable via a kernel command line option. The > > current integer value of 128 bits is a good default value. However, some > > user groups may want to use different values. For example, the SOGIS > > group now requires 125 bits at least (BSI, the participant at that group > > used to require 100 bits). NIST moved from 80 bits to 112 bits starting > > with 2014. > > > > It is therefore to be expected that in the future, this threshold may > > increase for different user groups. > > Speaking of random and kernel parameters... should we add random= digits> parameter to pass entropy from bootloader to the kernel? Everybody can see that string. How do you think that way of providing entropy is protected? > u-boot-SPL does DRAM calibration, for example, and I guess that may > provide some rather hard to guess values... > > [I initialy misread parameter below as "random_initize=" and thought > it does exactly this...] > Pavel > > > + random_initialized= [KNL] Set the threshold in bits at which the > > + Linux random number generator considers an output > > + entropy pool initialized. > > + Format: (must be >= 112 and <= size of output > > + entropy pool in bits) > > + Default: 128 > > + -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto-jitterentropy: Delete unnecessary checks before the function call "kzfree"
Am Dienstag, 23. Juni 2015, 23:20:21 schrieb SF Markus Elfring:
Hi Markus,
> From: Markus Elfring
> Date: Tue, 23 Jun 2015 22:30:21 +0200
>
> The kzfree() function tests whether its argument is NULL and then
> returns immediately. Thus the test around the call is not needed.
>
> This issue was detected by using the Coccinelle software.
Ack: the patch is correct and I was overzealous.
Nack: I just proposed a patch earlier today to avoid compiler warnings [1].
That patch clashes with yours. May I ask you to wait briefly to see whether
that patch will be accepted? If yes, it would be great if you could repost the
patch that applies to the changed code.
PS: when you are at it, maybe even the last line in the function can be
removed: setting the entropy_collector to NULL at that the end of the function
is moot as well.
Thanks.
[1] http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05196.html
>
> Signed-off-by: Markus Elfring
> ---
> crypto/jitterentropy.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c
> index d3c3045..22ded3e 100644
> --- a/crypto/jitterentropy.c
> +++ b/crypto/jitterentropy.c
> @@ -698,11 +698,9 @@ static struct rand_data
> *jent_entropy_collector_alloc(unsigned int osr,
>
> static void jent_entropy_collector_free(struct rand_data
> *entropy_collector) {
> - if (entropy_collector->mem)
> - kzfree(entropy_collector->mem);
> + kzfree(entropy_collector->mem);
> entropy_collector->mem = NULL;
> - if (entropy_collector)
> - kzfree(entropy_collector);
> + kzfree(entropy_collector);
> entropy_collector = NULL;
> }
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: jitterentropy - avoid compiler warnings
Am Dienstag, 23. Juni 2015, 10:41:03 schrieb Guenter Roeck: Hi Guenter, Geert, >On Tue, Jun 23, 2015 at 04:18:54PM +0200, Stephan Mueller wrote: >> Hi Geert, Guenter, >> >> may I ask that you check that the following patch compiles without errors >> or warnings on your systems? >No build failures for all architectures. Thank you very much for your help. Now, if Geert would be so kind and have a check on his OpenRISC to ensure that there are no compiler warnings, I would be happy. Though, does anybody have any idea what the AVR32 compiler warning about crypto/builtin.o not being relaxable mean and whether that is an issue? Note, when I was compiling AVR32, I saw some of these warnings for other builtin.o too. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto: jitterentropy - avoid compiler warnings
Am Dienstag, 23. Juni 2015, 08:31:10 schrieb Guenter Roeck: Hi Guenter, >On Tue, Jun 23, 2015 at 04:18:54PM +0200, Stephan Mueller wrote: >> Hi Geert, Guenter, >> >> may I ask that you check that the following patch compiles without errors >> or warnings on your systems? >Stephan, > >I applied your patch on top of the current mainline (which includes >the crypto updates for 4.2) and pushed it into my 'testing' branch. >You should be able to see the results in a couple of hours at >http://server.roeck-us.net:8010/builders, in the 'testing' column. > >The build system doesn't log warnings, but this should give us an idea >if the build passes for all architectures. > >I'll have a look myself later and let you know as well. Thank you very much! Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: jitterentropy - avoid compiler warnings
Hi Geert, Guenter,
may I ask that you check that the following patch compiles without errors or
warnings on your systems?
Though, when I test that patch with the AVR32 cross compiler, I get a warning
about the code being not relaxable.
Thank you very much.
---8<---
The core of the Jitter RNG is intended to be compiled with -O0. To
ensure that the Jitter RNG can be compiled on all architectures,
separate out the RNG core into a stand-alone C file that can be compiled
with -O0 which does not depend on any kernel include file.
As no kernel includes can be used in the C file implementing the core
RNG, any dependencies on kernel code must be extracted.
A second file provides the link to the kernel and the kernel crypto API
that can be compiled with the regular compile options of the kernel.
Signed-off-by: Stephan Mueller
---
crypto/Makefile | 4 +-
crypto/jitterentropy-kcapi.c | 208 ++
crypto/jitterentropy.c | 213 ---
3 files changed, 248 insertions(+), 177 deletions(-)
create mode 100644 crypto/jitterentropy-kcapi.c
diff --git a/crypto/Makefile b/crypto/Makefile
index 0077476..a16a7e7 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -106,7 +106,9 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) += rng.o
obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o
obj-$(CONFIG_CRYPTO_DRBG) += drbg.o
-obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o
+obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy_rng.o
+CFLAGS_jitterentropy.o = -O0
+jitterentropy_rng-y := jitterentropy.o jitterentropy-kcapi.o
obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c
new file mode 100644
index 000..b32d834
--- /dev/null
+++ b/crypto/jitterentropy-kcapi.c
@@ -0,0 +1,208 @@
+/*
+ * Non-physical true random number generator based on timing jitter --
+ * Linux Kernel Crypto API specific code
+ *
+ * Copyright Stephan Mueller , 2015
+ *
+ * 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 GPL2 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct rand_data;
+int jent_read_entropy(struct rand_data *ec, unsigned char *data,
+ unsigned int len);
+int jent_entropy_init(void);
+struct rand_data *jent_entropy_collector_alloc(unsigned int osr,
+ unsigned int flags);
+void jent_entropy_collector_free(struct rand_data *entropy_collector);
+
+/***
+ * Helper function
+ ***/
+
+__u64 jent_rol64(__u64 word, unsigned int shift)
+{
+ return rol64(word, shift);
+}
+
+void *jent_zalloc(unsigned int len)
+{
+ return kzalloc(len, GFP_KERNEL);
+}
+
+void jent_zfree(void *ptr)
+{
+ kzfree(ptr);
+}
+
+int jent_fips_enabled(void)
+{
+ return fips_enabled;
+}
+
+void jent_panic(char *s)
+{
+ panic(s);
+}
+
+void jent_memcpy(void *dest, const void *
Re: #pragma GCC warnings (was: Re: [PATCH] crypto: drbg - use pragmas for disabling optimization)
Am Dienstag, 23. Juni 2015, 17:21:06 schrieb Herbert Xu: Hi Herbert, > On Tue, Jun 23, 2015 at 11:17:23AM +0200, Geert Uytterhoeven wrote: > > I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0. > > > > With m68k-linux-gnu-gcc-4.1, which is still my default cross-compiler due > > to the good unused warning reporting, I get: > > > > crypto/jitterentropy.c:235: warning: ignoring #pragma GCC push_options > > crypto/jitterentropy.c:236: warning: ignoring #pragma GCC optimize > > crypto/jitterentropy.c:266: warning: ignoring #pragma GCC pop_options > > crypto/jitterentropy.c:295: warning: ignoring #pragma GCC push_options > > crypto/jitterentropy.c:296: warning: ignoring #pragma GCC optimize > > crypto/jitterentropy.c:336: warning: ignoring #pragma GCC pop_options > > crypto/jitterentropy.c:385: warning: ignoring #pragma GCC push_options > > crypto/jitterentropy.c:386: warning: ignoring #pragma GCC optimize > > crypto/jitterentropy.c:416: warning: ignoring #pragma GCC pop_options > > crypto/jitterentropy.c:517: warning: ignoring #pragma GCC push_options > > crypto/jitterentropy.c:518: warning: ignoring #pragma GCC optimize > > crypto/jitterentropy.c:580: warning: ignoring #pragma GCC pop_options > > Stephan, could you look into moving the relevant functions into > its own file which can then be compiled with -O0? Obviously any > dependency on kernel header files would have to be hidden using > functions outside of this file. I have separated all so far. However, there are two items left where I am not sure about: - asm/types.h: I need __u64 - linux/bitops.h: I need rol64 Can I safely include both header files or do I have to hide them too. If yes, how would I do that in a way that is satisfactory? Thanks. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma GCC warnings (was: Re: [PATCH] crypto: drbg - use pragmas for disabling optimization)
Am Dienstag, 23. Juni 2015, 17:21:06 schrieb Herbert Xu: Hi Herbert, >On Tue, Jun 23, 2015 at 11:17:23AM +0200, Geert Uytterhoeven wrote: >> I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0. >> >> With m68k-linux-gnu-gcc-4.1, which is still my default cross-compiler due >> to the good unused warning reporting, I get: >> >> crypto/jitterentropy.c:235: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:236: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:266: warning: ignoring #pragma GCC pop_options >> crypto/jitterentropy.c:295: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:296: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:336: warning: ignoring #pragma GCC pop_options >> crypto/jitterentropy.c:385: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:386: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:416: warning: ignoring #pragma GCC pop_options >> crypto/jitterentropy.c:517: warning: ignoring #pragma GCC push_options >> crypto/jitterentropy.c:518: warning: ignoring #pragma GCC optimize >> crypto/jitterentropy.c:580: warning: ignoring #pragma GCC pop_options > >Stephan, could you look into moving the relevant functions into >its own file which can then be compiled with -O0? Obviously any >dependency on kernel header files would have to be hidden using >functions outside of this file. I will look into it. Thanks Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v5 3/4] crypto: rsa: add a new rsa generic implementation
Am Montag, 15. Juni 2015, 18:49:15 schrieb Tadeusz Struk:
Hi Tadeusz,
> On 06/15/2015 04:23 PM, Stephan Mueller wrote:
> >> + /* In FIPS mode only allow key size minimum 2K */
> >>
> >> > +if (fips_enabled && (mpi_get_size(key->n) < 256)) {
> >
> > Considering my previous email, shouldn't that check rather be
> >
> > if (fips_enabled &&
> >
> > ((mpi_get_size(key->n) != 256) || (mpi_get_size(key->n) != 384))
>
> I'm not familiar with the FIPS requirements. I checked the NIST
> recommendations witch states that RSA: |n| >= 2048 is acceptable. If FIPS
> allows 2K and 3K only then we need to change it.
The reason for exclusive 2k/3k is the CAVS testing: there is only the ability
to test 2/3k. Longer key sizes are even not allowed as per SP800-131A in favor
of EC.
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v5 3/4] crypto: rsa: add a new rsa generic implementation
Am Montag, 15. Juni 2015, 13:18:47 schrieb Tadeusz Struk:
Hi Tadeusz,
> Add a new rsa generic SW implementation.
> This implements only cryptographic primitives.
Thank you, that seems to address the issues around the FIPS side including the
self test code.
Though, I have one question:
> +
> +int rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
> + const void *value, size_t vlen)
> +{
> + struct crypto_akcipher *tfm = context;
> + struct rsa_key *key = tfm->key;
> +
> + key->n = mpi_read_raw_data(value, vlen);
> +
> + if (!key->n)
> + return -ENOMEM;
> +
> + /* In FIPS mode only allow key size minimum 2K */
> + if (fips_enabled && (mpi_get_size(key->n) < 256)) {
Considering my previous email, shouldn't that check rather be
if (fips_enabled &&
((mpi_get_size(key->n) != 256) || (mpi_get_size(key->n) != 384))
?
> + pr_err("RSA: key size not allowed in FIPS mode\n");
> + mpi_free(key->n);
> + key->n = NULL;
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +int rsa_get_e(void *context, size_t hdrlen, unsigned char tag,
> + const void *value, size_t vlen)
> +{
> + struct crypto_akcipher *tfm = context;
> + struct rsa_key *key = tfm->key;
> +
> + key->e = mpi_read_raw_data(value, vlen);
> +
> + if (!key->e)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +int rsa_get_d(void *context, size_t hdrlen, unsigned char tag,
> + const void *value, size_t vlen)
> +{
> + struct crypto_akcipher *tfm = context;
> + struct rsa_key *key = tfm->key;
> +
> + key->d = mpi_read_raw_data(value, vlen);
> +
> + if (!key->d)
> + return -ENOMEM;
> +
> + /* In FIPS mode only allow key size minimum 2K */
> + if (fips_enabled && (mpi_get_size(key->d) < 256)) {
dto.
> + pr_err("RSA: key size not allowed in FIPS mode\n");
> + mpi_free(key->d);
> + key->d = NULL;
> + return -EINVAL;
> + }
> + return 0;
> +}
> +
Thanks
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 1/4] MPILIB: add mpi_read_buf(), mpi_copy() and mpi_get_size() helpers
Am Donnerstag, 11. Juni 2015, 12:05:38 schrieb Tadeusz Struk:
Hi Tadeusz,
>+ */
>+void *mpi_get_buffer(MPI a, unsigned *nbytes, int *sign)
>+{
>+ uint8_t *buf, *p;
>+ int n, ret;
>+
>+ if (!nbytes)
>+ return NULL;
>+
>+ n = mpi_get_size(a);
Shouldn't n be unsigned int?
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v4 2/4] crypto: add PKE API
Am Thursday 11 June 2015, 12:05:44 schrieb Tadeusz Struk:
Hi Tadeusz,
>+
>+static int akcipher_clone_key(struct crypto_akcipher *tfm,
>+const struct public_key *pkey)
>+{
>+ int i, ret = 0;
>+
>+ tfm->pkey = kzalloc(sizeof(*tfm->pkey), GFP_KERNEL);
>+
>+ if (!tfm->pkey)
>+ return -ENOMEM;
>+
>+ for (i = 0; i < ARRAY_SIZE(tfm->pkey->mpi); i++) {
>+ if (!pkey->mpi[i])
>+ continue;
>+
>+ if (mpi_copy(&tfm->pkey->mpi[i], pkey->mpi[i])) {
>+ akcipher_free_key(tfm->pkey);
>+ tfm->pkey = NULL;
>+ ret = -ENOMEM;
>+ break;
>+ }
>+ }
>+ return ret;
>+}
The testmgr code can mark an entire cipher implementation as fips_allowed=1 as
already done for RSA. However, unlike with the other ciphers, that flag must
go in conjunction with the used key sizes.
For FIPS mode, the following restrictions apply:
- RSA: 2048/3072
- DSA: L 2048 / N 224; L 2048 / N 256; L 3072 / N 256
- ECDSA: only the NIST curves
Any other key sizes for the given ciphers is not allowed in FIPS mode.
Should that constraint be considered here?
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v13 1/2] crypto: AF_ALG: add AEAD support
Am Thursday 11 June 2015, 15:59:29 schrieb Tadeusz Struk:
Hi Tadeusz,
>Hi Stephan,
>
>On 02/28/2015 11:50 AM, Stephan Mueller wrote:
>> +err = af_alg_wait_for_completion(ctx->enc ?
>> + crypto_aead_encrypt(&ctx->aead_req) :
>> + crypto_aead_decrypt(&ctx->aead_req),
>> + &ctx->completion);
>> +
>> +if (err) {
>> +/* EBADMSG implies a valid cipher operation took place */
>> +if (err == -EBADMSG)
>> +aead_put_sgl(sk);
>> +goto unlock;
>
>Shouldn't we free the TX sgl regardless of the error was?
>Or do we expect that the user will try to read again and it will be Ok the
>second time? Hope you still remember :)
It is the latter: as the crypto was not completed properly, leave the data in
memory. This may allow a user to send more data if he needs to for completing
the AEAD operation.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] trivial: report backend_cra_name when allocation fails
Am Thursday 11 June 2015, 20:09:29 schrieb Sergey Senozhatsky: Hi Sergey, >Thanks. > >FWIW, here is my .config (Stephan has requested) Thank you very much. But I think Herbert already found the issue: SHA needs to be selected too (which I erroneously thought is implicitly selected with HMAC). Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] crypto/drbg: report backend_cra_name when allocation fails
Am Wednesday 10 June 2015, 22:27:48 schrieb Sergey Senozhatsky: Hi Sergey, >Be more verbose and also report ->backend_cra_name when >crypto_alloc_shash() or crypto_alloc_cipher() fail in >drbg_init_hash_kernel() or drbg_init_sym_kernel() >correspondingly. > >Example > DRBG: could not allocate digest TFM handle: hmac(sha256) > >Signed-off-by: Sergey Senozhatsky Headscratch -- the Kconfig should have HMAC selected for compilation. When HMAC is available (regardless whether it is a module or not), it is pulled in by the kernel crypto API. Thus, there should not have been the error that HMAC is missing. Can you send your .config file, please? Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] crypto: drbg - reseed often if seedsource is degraded
Changes v2:
* port the patch to current cryptodev tree plus the async seeding DRBG patches
---8<---
As required by SP800-90A, the DRBG implements are reseeding threshold.
This threshold is at 2**48 (64 bit) and 2**32 bit (32 bit) as
implemented in drbg_max_requests.
With the recently introduced changes, the DRBG is now always used as a
stdrng which is initialized very early in the boot cycle. To ensure that
sufficient entropy is present, the Jitter RNG is added to even provide
entropy at early boot time.
However, the 2nd seed source, the nonblocking pool, is usually
degraded at that time. Therefore, the DRBG is seeded with the Jitter RNG
(which I believe contains good entropy, which however is questioned by
others) and is seeded with a degradded nonblocking pool. This seed is
now used for quasi the lifetime of the system (2**48 requests is a lot).
The patch now changes the reseed threshold as follows: up until the time
the DRBG obtains a seed from a fully iniitialized nonblocking pool, the
reseeding threshold is lowered such that the DRBG is forced to reseed
itself resonably often. Once it obtains the seed from a fully
initialized nonblocking pool, the reseed threshold is set to the value
required by SP800-90A.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 12 +++-
include/crypto/drbg.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index c6cbf13..5fad297 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1088,6 +1088,9 @@ static void drbg_async_seed(struct work_struct *work)
__drbg_seed(drbg, &seedlist, true);
+ if (drbg->seeded)
+ drbg->reseed_threshold = drbg_max_requests(drbg);
+
mutex_unlock(&drbg->drbg_mutex);
memzero_explicit(entropy, entropylen);
@@ -1334,7 +1337,7 @@ static int drbg_generate(struct drbg_state *drbg,
* 9.3.1 step 6 and 9 supplemented by 9.3.2 step c is implemented
* here. The spec is a bit convoluted here, we make it simpler.
*/
- if ((drbg_max_requests(drbg)) < drbg->reseed_ctr)
+ if (drbg->reseed_threshold < drbg->reseed_ctr)
drbg->seeded = false;
if (drbg->pr || !drbg->seeded) {
@@ -1478,6 +1481,12 @@ static int drbg_prepare_hrng(struct drbg_state *drbg)
drbg->jent = crypto_alloc_rng("jitterentropy_rng", 0, 0);
+ /*
+* Require frequent reseeds until the seed source is fully
+* initialized.
+*/
+ drbg->reseed_threshold = 50;
+
return err;
}
@@ -1522,6 +1531,7 @@ static int drbg_instantiate(struct drbg_state *drbg,
struct drbg_string *pers,
drbg->core = &drbg_cores[coreref];
drbg->pr = pr;
drbg->seeded = false;
+ drbg->reseed_threshold = drbg_max_requests(drbg);
ret = drbg_alloc_state(drbg);
if (ret)
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index fad6450..9756c70 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -111,6 +111,7 @@ struct drbg_state {
unsigned char *C;
/* Number of RNG requests since last reseed -- 10.1.1.1 1c) */
size_t reseed_ctr;
+ size_t reseed_threshold;
/* some memory the DRBG can use for its operation */
unsigned char *scratchpad;
void *priv_data;/* Cipher handle */
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] crypto: drbg - lower reseed threshold if seed source is degraded
Am Dienstag, 9. Juni 2015, 23:26:05 schrieb Herbert Xu: Hi Herbert, > On Tue, Jun 09, 2015 at 05:22:32PM +0200, Stephan Mueller wrote: > > Am Dienstag, 9. Juni 2015, 22:25:25 schrieb Herbert Xu: > > > > Hi Herbert, > > > > > Anyway, I'm happy to apply this. However, the patch is corrupted > > > so please resend it without the white-space damage/line wrapping. > > > > As this patch would clash with the async seeding patch, shall I develop > > this patch on top of your async patch set? > > Either way is fine. I can fix it up when applying as they don't > conceptually conflict. I see one: the reset of the threshold to the "normal" value must happen at two places: the one place is in the async handler. The 2nd place is when the request to random.c returns 0 (i.e. fully initialized). The 2nd location is different between both code bases. > > Thanks, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] crypto: drbg - lower reseed threshold if seed source is degraded
Am Dienstag, 9. Juni 2015, 22:25:25 schrieb Herbert Xu: Hi Herbert, > > Anyway, I'm happy to apply this. However, the patch is corrupted > so please resend it without the white-space damage/line wrapping. As this patch would clash with the async seeding patch, shall I develop this patch on top of your async patch set? > > Thanks, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] crypto: drbg - Use callback API for random readiness
Am Dienstag, 9. Juni 2015, 18:19:41 schrieb Herbert Xu:
Hi Herbert,
first of all, thanks a lot for your help. I have tested the patch set.
...
> /*
> * DRBG instantiation function as required by SP800-90A - this function
> * sets up the DRBG handle, performs the initial seeding and all sanity
> @@ -1517,15 +1531,23 @@ static int drbg_instantiate(struct drbg_state *drbg,
> struct drbg_string *pers, if (drbg->d_ops->crypto_init(drbg))
> goto err;
>
> + ret = drbg_prepare_hrng(drbg);
> + if (ret)
> + goto free_everything;
> +
> + if (IS_ERR(drbg->jent)) {
> + ret = PTR_ERR(drbg->jent);
> + drbg->jent = NULL;
> + goto free_everything;
I am wondering about the error here. The Jitter RNG has in its init function a
test to see whether the RNG really works on the hardware as there are still
systems out there that have no high-res timer (e.g. I have seen that on old
Android phones). If the Jitter RNG detects that the system is not appropriate,
it will not register.
On such systems, the error here would imply that the DRBG does not instantiate
and we have no stdrng.
> + }
> +
> reseed = false;
> }
>
> ret = drbg_seed(drbg, pers, reseed);
>
> - if (ret && !reseed) {
> - drbg->d_ops->crypto_fini(drbg);
> - goto err;
> - }
> + if (ret && !reseed)
> + goto free_everything;
>
> mutex_unlock(&drbg->drbg_mutex);
> return ret;
> @@ -1535,6 +1557,11 @@ err:
> unlock:
> mutex_unlock(&drbg->drbg_mutex);
> return ret;
> +
> +free_everything:
> + mutex_unlock(&drbg->drbg_mutex);
> + drbg_uninstantiate(drbg);
> + return ret;
> }
>
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] crypto: drbg - use pragmas for disabling optimization
Hi,
I performed measurements of the upper and lower boundary of the minimum and
Shannon entropy for the RNG before the patch and after the patch. The values
are very similar which demonstrates that the change does not affect the
cryptographic characteristics of the RNG.
The tests are available at:
[1] shows the lower boundary of the fully non-optimized RNG
[2] shows the lower boundary of the RNG with the patch below
[3] shows the upper boundary of the fully non-optimized RNG
[4] shows the upper boundary of the RNG with the patch below
The pictures are fully explained in [5], but the key values are the minimum
and Shannon entropy numbers in the legend of the graphs.
[1]
http://www.eperm.de/userspace-foldtime-testO0.data-single-time-dist-delta-3036-hist.pdf
[2]
http://www.eperm.de/userspace-foldtime-test-pragmas-O2.data-single-time-dist-delta-2370-hist.pdf
[3]
http://www.eperm.de/userspace-foldtime-testO0.data-varying-time-dist-delta-7302-hist.pdf
[4]
http://www.eperm.de/userspace-foldtime-test-pragmas-O2.data-varying-time-dist-delta-7055-hist.pdf
[5] http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf
---8<---
Replace the global -O0 compiler flag from the Makefile with GCC
pragmas to mark only the functions required to be compiled without
optimizations.
This patch also adds a comment describing the rationale for the
functions chosen to be compiled without optimizations.
Signed-off-by: Stephan Mueller
---
crypto/Makefile| 1 -
crypto/jitterentropy.c | 30 ++
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/crypto/Makefile b/crypto/Makefile
index 83b3c44..c842035 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -97,7 +97,6 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) += rng.o
obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o
obj-$(CONFIG_CRYPTO_DRBG) += drbg.o
-CFLAGS_jitterentropy.o = -O0
obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o
obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c
index 20dc178..9ba99e6 100644
--- a/crypto/jitterentropy.c
+++ b/crypto/jitterentropy.c
@@ -57,10 +57,6 @@
#include
#include
-#ifdef __OPTIMIZE__
- #error "The CPU Jitter random number generator must not be compiled with
optimizations. See documentation. Use the compiler switch -O0 for compiling
jitterentropy.c."
-#endif
-
/* The entropy pool */
struct rand_data {
/* all data values that are vital to maintain the security
@@ -188,6 +184,20 @@ static __u64 jent_loop_shuffle(struct rand_data *ec,
* Noise sources
***/
+/*
+ * The disabling of the optimizations is performed as documented and assessed
+ * thoroughly in http://www.chronox.de/jent.html. However, instead of disabling
+ * the optimization of the entire C file, only the main functions the jitter is
+ * measured for are not optimized. These functions include the noise sources as
+ * well as the main functions triggering the noise sources. As the time
+ * measurement is done from one invocation of the jitter noise source to the
+ * next, even the execution jitter of the code invoking the noise sources
+ * contribute to the overall randomness as well. The behavior of the RNG and
the
+ * statistical characteristics when only the mentioned functions are not
+ * optimized is almost equal to the a completely non-optimized RNG compilation
+ * as tested with the test tools provided at the initially mentioned web site.
+ */
+
/**
* CPU Jitter noise source -- this is the noise source based on the CPU
* execution time jitter
@@ -222,6 +232,8 @@ static __u64 jent_loop_shuffle(struct rand_data *ec,
*
* @return Number of loops the folding operation is performed
*/
+#pragma GCC push_options
+#pragma GCC optimize ("-O0")
static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
__u64 *folded, __u64 loop_cnt)
{
@@ -251,6 +263,7 @@ static __u64 jent_fold_time(struct rand_data *ec, __u64
time,
*folded = new;
return fold_loop_cnt;
}
+#pragma GCC pop_options
/**
* Memory Access noise source -- this is a noise source based on variations in
@@ -279,6 +292,8 @@ static __u64 jent_fold_time(struct rand_data *ec, __u64
time,
*
* @return Number of memory access operations
*/
+#pragma GCC push_options
+#pragma GCC optimize ("-O0")
static unsigned int jent_memaccess(struct rand_data *ec, __u64 loop_cnt)
{
unsigned char *tmpval = NULL;
@@ -318,6 +333,7 @@ static unsigned int jent_memaccess(struct rand_data *ec,
__u64 loop_cnt)
}
return i;
}
+#pragma GCC pop_options
/***
* Start of entropy processing logic
@@ -366,6 +382,8 @@ static void jent_stuck(struct ra
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 16:51:24 schrieb Guenter Roeck: Hi Guenter, > >Yes, that fixes the problem (after I also removed the associated #error from >jitterentropy.c). Thank you for the confirmation. The patch will come tonight on this issue as I tested the cryptographic impact already. Thanks a lot for your help. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 16:30:09 schrieb Guenter Roeck: Hi Guenter, > >get_cycles is implemented as static inline which executes mfspr(SPR_TTCR). >SPR_TTCR is a constant. Normally that information seems to be passed on, >but not when get_cycles() is compiled through jitterentropy. > >Any idea what might cause this ? Then it may be the optimization issue as well that Peter indicated. May I ask you for testing purposes (I do not have an OpenRISC) to remove the following line from crypto/Makefile: CFLAGS_jitterentropy.o = -O0 Note, that should just serve for testing. I will post a patch later that will replace the -O0 statement with a pragma. Thanks a lot. > >Thanks, >Guenter Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 12:54:12 schrieb Guenter Roeck: Hi Guenter, Thanks for the note. ... > >--- > >openrisc:defconfig: > >In file included from ./arch/openrisc/include/asm/timex.h:23:0, > ... > from crypto/jitterentropy.c:52: >./arch/openrisc/include/asm/spr.h: In function 'jent_loop_shuffle': >./arch/openrisc/include/asm/spr.h:30:2: warning: asm operand 1 probably >doesn't match constraints >./arch/openrisc/include/asm/spr.h:30:2: error: impossible constraint in 'asm' I received this one also before. But that seems to be an error on the OpenRISC platform as the random_get_entropy() function or the get_cycles function is not implemented as defined. The crypto code uses the following which triggers the issue: __u64 tmp = 0; tmp = random_get_entropy(); That one seems to be an appropriate use of random_get_entropy() which on almost all arches is an alias for get_cycles(). > >--- > >nios2:3c120_defconfig: > >ERROR: "get_cycles" [crypto/jitterentropy.ko] undefined! Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Monday 08 June 2015, 14:36:30 schrieb Peter Zijlstra:
Hi Peter,
>
>Would something like
>
>#pragma GCC push_options
>#pragma GCC optimize ("-O0")
>static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> __u64 *folded, __u64 loop_cnt)
>{
> ...
>}
>#pragma GCC pop_options
>
>Be an option to allow the file to be compiled with regular optimizations
>enabled?
After doing some tests, I see that neither the min entropy nor the Shannon
Entropy of the raw noise is affected by using the mentioned pragmas at the
right locations.
So I will prepare a patch tonight.
Just for my edification: why does an -O0 on a self contained file break the
compile run? Any why do the pragmas work?
Thanks
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20150529, in crypto/jitterentropy.c
Am Montag, 8. Juni 2015, 14:36:30 schrieb Peter Zijlstra:
Hi Peter,
> Adding Stephan to Cc.
>
> On Mon, 2015-06-08 at 20:25 +0800, Herbert Xu wrote:
> > On Mon, Jun 08, 2015 at 03:21:09PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 29, 2015 at 10:14 PM, Jim Davis wrote:
> > > > Building with the attached random configuration file,
> > >
> > > Hit the very same error against next-20150605.
> > >
> > > The issue with that file we have no compiler optimization enabled. So,
> > > guys, how you would recommend to fix it?
> >
> > Stephan, can we get rid of the no optimisation requirement?
>
> Would something like
>
> #pragma GCC push_options
> #pragma GCC optimize ("-O0")
> static __u64 jent_fold_time(struct rand_data *ec, __u64 time,
> __u64 *folded, __u64 loop_cnt)
> {
> ...
> }
> #pragma GCC pop_options
>
> Be an option to allow the file to be compiled with regular optimizations
> enabled?
Yes, that is also possible. I was not aware of the fact that the optimization
is the problem. I got another report fom Fengguang Wu about a compile issue on
AVR32 which I found out relates to the same issue.
I will prepare a patch shortly.
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] crypto: drbg - lower reseed threshold if seed source is degraded
Hi,
may I ask for review of the following patch. I would like particular feedback
to the initial threshold value, which the patch currently sets to 50 (requests
by a caller to the DRBG for random numbers). Thank you.
I am not sure about this value because there are two conflicting issues
revolving around this value:
1. We have to ensure that the DRBG has a sufficiently entropic internal state.
That would mean, I should set that value as low as possible.
2. This is the more problematic one: when considering information theory, if
you draw from a DRNG (which the nonblocking pool is in the worst case -- and
the boot time discussed below is our worst case) that is not fully seeded, you
reduce the entropy in that DRNG (contrary to conventional wisdom). For the
discussion, let us assume the worst case that there is coming in one bit of
entropy at a time into the discussed DRNG. In between the addition of each bit
of entropy, an attacker can access the DRNG (i.e. the SHA1 output of the
nonblocking_pool). When only one bit of entropy is added to the
nonblocking_pool, the attack complexity would be 1 bit. When an attacker would
access the nonblocking_pool after each received bit, in the worst case, the
attack complexity is not 2**128 but rather 256 (i.e. 1 bit for each individual
attack between the addition of one new bit of entropy). So, the total attack
complexity is the sum of the individual attack complexities (i.e. the
complexity added after the previous attack is performed). This issue is
aggravated by the nonblocking pool as the entropy counter used for declaring
that the threshold defining the that nonblocking pool is initialized is never
decreased by requests, but only increased. So, with that issue in mind, we
want to set the reseed threshold of the DRBG to rather a higher level.
Thus I am struggling to find the right(TM) initial value for the reseeding
threshold.
Or maybe you can tell me that there is no need for the patch to begin with as
the initial seed plus the async request to the nonblocking pool is good as is.
:-)
Note, this patch is on top of the patch updating the async reseeding sent out
yesterday.
---8<---
As required by SP800-90A, the DRBG implements are reseeding threshold.
This threshold is at 2**48 (64 bit) and 2**32 bit (32 bit) as
implemented in drbg_max_requests.
With the recently introduced changes, the DRBG is now always used as a
stdrng which is initialized very early in the boot cycle. To ensure that
sufficient entropy is present, the Jitter RNG is added to even provide
entropy at early boot time.
However, the 2nd seed source, the nonblocking pool, is usually
degraded at that time. Therefore, the DRBG is seeded with the Jitter RNG
(which I believe contains good entropy, which however is questioned by
others) and is seeded with a degradded nonblocking pool. This seed is
now used for quasi the lifetime of the system (2**48 requests is a lot).
The patch now changes the reseed threshold as follows: up until the time
the DRBG obtains a seed from a fully iniitialized nonblocking pool, the
reseeding threshold is lowered such that the DRBG is forced to reseed
itself resonably often. Once it obtains the seed from a fully
initialized nonblocking pool, the reseed threshold is set to the value
required by SP800-90A.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 35 ++-
include/crypto/drbg.h | 1 +
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 3fed67e..0ea4d3c 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1075,10 +1075,16 @@ static void drbg_async_seed(void *private)
mutex_lock(&drbg->drbg_mutex);
ret = __drbg_seed(drbg, &seedlist, true);
- /* If nonblocking pool is initialized, deactivate Jitter RNG */
- if (!ret && drbg->jent) {
- crypto_free_rng(drbg->jent);
- drbg->jent = NULL;
+ /*
+* If nonblocking pool is initialized: set reseeding threshold to
+* regular threshold and deactivate Jitter RNG.
+*/
+ if (!ret) {
+ drbg->reseed_threshold = drbg_max_requests(drbg);
+ if (drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
}
memzero_explicit(entropy, entropylen);
mutex_unlock(&drbg->drbg_mutex);
@@ -1157,10 +1163,16 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
entropylen * 2);
}
- /* If nonblocking pool is initialized, deactivate Jitter RNG
*/
- if (!ret && drbg->jent) {
- crypto_free_rng(drbg->jent);
- drbg->jent = NULL;
+ /*
+* If nonblocking pool is initialized: set reseeding threshol
[PATCH] crypto: use list to stage async seeding requests
This patch uses a list to track the asynchronous seeding requests until
the nonblocking pool is fully initialized. The random.c is provided with
two API calls: the get_blocking_random_bytes_cb allows the caller to
provide a callback function that is triggered once the nonblocking pool
is initialized. If the nonblocking pool is already initialized at the
time of invocation, the function is a noop. The second API call of
get_blocking_random_bytes_cancel allows the caller to cancel an
outstanding request.
The previous approach used a waitqueue for maintaining the requests
until the nonblocking pool is initialized. In some circumstances, the
wait can be very long (in the orders of minutes) where the use of
waitqueues is not appropriate.
The patch also removes the entropy buffer registered with the DRBG
handle in favor of stack variables to hold the seed data.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 112 -
drivers/char/random.c | 99 +++
include/crypto/drbg.h | 4 --
include/linux/random.h | 4 +-
4 files changed, 149 insertions(+), 70 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 04836b4..7339cc5 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1056,25 +1056,31 @@ static inline int __drbg_seed(struct drbg_state *drbg,
struct list_head *seed,
return ret;
}
-static void drbg_async_seed(struct work_struct *work)
+static void drbg_async_seed(void *private)
{
struct drbg_string data;
LIST_HEAD(seedlist);
- struct drbg_state *drbg = container_of(work, struct drbg_state,
- seed_work);
- int ret;
+ struct drbg_state *drbg = (struct drbg_state *)private;
+ unsigned char entropy[32];
+ size_t entropylen = drbg_sec_strength(drbg->core->flags);
+ int ret = 0;
- get_blocking_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ BUG_ON(!entropylen);
+ BUG_ON(entropylen > sizeof(entropy));
+ get_random_bytes(entropy, entropylen);
- drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
+ drbg_string_fill(&data, entropy, entropylen);
list_add_tail(&data.list, &seedlist);
+
mutex_lock(&drbg->drbg_mutex);
ret = __drbg_seed(drbg, &seedlist, true);
+
+ /* If nonblocking pool is initialized, deactivate Jitter RNG */
if (!ret && drbg->jent) {
crypto_free_rng(drbg->jent);
drbg->jent = NULL;
}
- memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ memzero_explicit(entropy, entropylen);
mutex_unlock(&drbg->drbg_mutex);
}
@@ -1093,6 +1099,8 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
bool reseed)
{
int ret = 0;
+ unsigned char entropy[((32 + 16) * 2)];
+ size_t entropylen = drbg_sec_strength(drbg->core->flags);
struct drbg_string data1;
LIST_HEAD(seedlist);
@@ -1108,23 +1116,51 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
+ /*
+* Gather entropy equal to the security strength of the DRBG.
+* With a derivation function, a nonce is required in addition
+* to the entropy. A nonce must be at least 1/2 of the security
+* strength of the DRBG in size. Thus, entropy + nonce is 3/2
+* of the strength. The consideration of a nonce is only
+* applicable during initial seeding.
+*/
+ BUG_ON(!entropylen);
+ if (!reseed)
+ entropylen = ((entropylen + 1) / 2) * 3;
+ BUG_ON((entropylen * 2) > sizeof(entropy));
+
+ /*
+* Trigger async seeding: This function may not trigger the
+* async callback in case the nonblocking is filled. To avoid
+* a race between get_random_bytes operating on a not yet
+* initialized nonblocking pool and get_blocking_random_bytes_cb
+* already operating on an initialized nonblocking pool and thus
+* not calling the async callback, invoke the async trigger
+* before get_random_bytes.
+*/
+ ret = get_blocking_random_bytes_cb(drbg, drbg_async_seed);
+
/* Get seed from in-kernel /dev/urandom */
- get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ get_random_bytes(entropy, entropylen);
/* Get
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Freitag, 5. Juni 2015, 13:28:06 schrieb Herbert Xu: Hi Herbert, > > Steffen, I think we need to revisit the idea of having a list > of callbacks. Ok, I will reactivate my patch with the list. > > Cheers, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v3 3/3] crypto: add tests vectors for RSA
Am Mittwoch, 3. Juni 2015, 15:44:24 schrieb Tadeusz Struk:
Hi Tadeusz,
> New test vectors for RSA algorithm.
>
> Signed-off-by: Tadeusz Struk
> ---
> crypto/testmgr.c | 151
> ++ crypto/testmgr.h |
> 86 +++
> 2 files changed, 237 insertions(+)
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 717d6f2..54a5412 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -30,6 +30,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "internal.h"
>
> @@ -116,6 +118,11 @@ struct drbg_test_suite {
> unsigned int count;
> };
>
> +struct akcipher_test_suite {
> + struct akcipher_testvec *vecs;
> + unsigned int count;
> +};
> +
> struct alg_test_desc {
> const char *alg;
> int (*test)(const struct alg_test_desc *desc, const char *driver,
> @@ -130,6 +137,7 @@ struct alg_test_desc {
> struct hash_test_suite hash;
> struct cprng_test_suite cprng;
> struct drbg_test_suite drbg;
> + struct akcipher_test_suite akcipher;
> } suite;
> };
>
> @@ -1825,6 +1833,139 @@ static int alg_test_drbg(const struct alg_test_desc
> *desc, const char *driver,
>
> }
>
> +static int do_test_rsa(struct crypto_akcipher *tfm,
> +struct akcipher_testvec *vecs)
> +{
> + struct akcipher_request *req;
> + struct public_key pkey;
> + void *outbuf_enc = NULL;
> + void *outbuf_dec = NULL;
> + struct tcrypt_result result;
> + unsigned int out_len = vecs->c_size;
> + int err = -ENOMEM;
> +
> + req = akcipher_request_alloc(tfm, GFP_KERNEL);
> + if (!req)
> + return err;
> +
> + pkey.rsa.n = mpi_read_raw_data(vecs->pub_key_n, vecs->pub_key_n_size);
> + if (!pkey.rsa.n)
> + goto free_req;
> +
> + pkey.rsa.e = mpi_read_raw_data(vecs->pub_key_e, vecs->pub_key_e_size);
> + if (!pkey.rsa.e)
> + goto free_n;
> +
> + pkey.rsa.d = mpi_read_raw_data(vecs->sec_key_d, vecs->sec_key_d_size);
> + if (!pkey.rsa.d)
> + goto free_e;
> +
> + outbuf_enc = kzalloc(vecs->c_size, GFP_KERNEL);
> + if (!outbuf_enc)
> + goto free_d;
> +
> + /* Run RSA encrypt - c = m^e mod n;*/
> + init_completion(&result.completion);
> + crypto_akcipher_setkey(tfm, &pkey);
> + akcipher_request_set_crypt(req, vecs->m, outbuf_enc, vecs->m_size,
> +out_len, &out_len);
> + akcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
> + tcrypt_complete, &result);
> + err = wait_async_op(&result, crypto_akcipher_encrypt(req));
> + if (err) {
> + pr_err("alg: rsa: encrypt test failed. err %d\n", err);
> + goto free_all;
> + }
> +
> + if (out_len != vecs->c_size) {
> + err = -EINVAL;
> + goto free_all;
> + }
> +
May I ask that the outbuf_enc is memcmp()ed with an expected value? This check
is required for FIPS 140-2 compliance. Without that memcmp, FIPS 140-2
validations will not be successful.
> + outbuf_dec = kzalloc(out_len, GFP_KERNEL);
> + if (!outbuf_dec) {
> + err = -ENOMEM;
> + goto free_all;
> + }
> +
> + init_completion(&result.completion);
> + akcipher_request_set_crypt(req, outbuf_enc, outbuf_dec, vecs->c_size,
> +out_len, &out_len);
> + /* Run RSA decrypt - m = c^d mod n;*/
> + err = wait_async_op(&result, crypto_akcipher_decrypt(req));
> + if (err) {
> + pr_err("alg: rsa: decrypt test failed. err %d\n", err);
> + goto free_all;
> + }
> +
> + if (out_len != vecs->m_size) {
> + err = -EINVAL;
> + goto free_all;
> + }
> +
> + /* verify that decrypted message is equal to the original msg */
> + if (memcmp(vecs->m, outbuf_dec, vecs->m_size)) {
> + pr_err("alg: rsa: encrypt test failed. Invalid output\n");
> + err = -EINVAL;
> + }
> +free_all:
> + kfree(outbuf_dec);
> + kfree(outbuf_enc);
> +free_d:
> + mpi_free(pkey.rsa.d);
> +free_e:
> + mpi_free(pkey.rsa.e);
> +free_n:
> + mpi_free(pkey.rsa.n);
> +free_req:
> + akcipher_request_free(req);
> + return err;
> +}
> +
> +static int test_rsa(struct crypto_akcipher *tfm, struct akcipher_testvec
> *vecs, + unsigned int tcount)
> +{
> + int ret, i;
> +
> + for (i = 0; i < tcount; i++) {
> + ret = do_test_rsa(tfm, vecs++);
> + if (ret) {
> + pr_err("alg: rsa: test failed on vector %d\n", i + 1);
> + return ret;
> + }
> + }
> + return 0;
> +}
> +
> +static int test_akcipher(struct crypto_akcipher *tfm, const char *alg,
> + struct akcipher_testvec *vecs, unsigned int tcount)
> +{
> +
Re: [PATCH 1/2] Doc:crypto: Fix typo in crypto-API.tmpl
Am Donnerstag, 4. Juni 2015, 00:01:20 schrieb Masanari Iida: Hi Masanari, > This patch fix some spelling typo found in crypto-API.tmpl > > Signed-off-by: Masanari Iida Acked-by: Stephan Mueller -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Doc:crypto: Fix typo in crypto-API.xml
Am Donnerstag, 4. Juni 2015, 00:01:21 schrieb Masanari Iida: Hi Masanari, > This patch fix some typos found in crypto-API.xml. > It is because the file is generated from comments in sources, > so I had to fix typo in sources. > > Signed-off-by: Masanari Iida Acked-by: Stephan Mueller -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the crypto tree
Am Donnerstag, 28. Mai 2015, 21:40:49 schrieb Stephen Rothwell:
Hi Stephen,
>Hi Herbert,
>
>After merging the crypto tree, today's linux-next build (powerpc
>allyesconfig) failed like this:
>
>crypto/jitterentropy.c: In function 'jent_get_nstime':
>crypto/jitterentropy.c:135:5: error: implicit declaration of function
>'timekeeping_valid_for_hres' [-Werror=implicit-function-declaration] (0 ==
>timekeeping_valid_for_hres()) &&
> ^
>
>Caused by commit bb5530e40824 ("crypto: jitterentropy - add
>jitterentropy RNG").
>
>I have reverted that commit for today.
The fix has been added to the cryptodev-2.6 this morning:
cf58fcb1bea9e0fcf3447bdb959ef5bcd22cfbcb
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 1/5] random: Blocking API for accessing nonblocking_pool
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 12
include/linux/random.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..0bb7cb2 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1245,6 +1245,18 @@ void get_random_bytes(void *buf, int nbytes)
EXPORT_SYMBOL(get_random_bytes);
/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+void get_blocking_random_bytes(void *buf, int nbytes)
+{
+ if (unlikely(nonblocking_pool.initialized == 0))
+ wait_event(urandom_init_wait, nonblocking_pool.initialized);
+ extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
+}
+EXPORT_SYMBOL(get_blocking_random_bytes);
+
+/*
* This function will use the architecture-specific hardware random
* number generator if it is available. The arch-specific hw RNG will
* almost certainly be faster than what we can do in software, but it
diff --git a/include/linux/random.h b/include/linux/random.h
index b05856e..796267d 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -14,6 +14,7 @@ extern void add_input_randomness(unsigned int type, unsigned
int code,
extern void add_interrupt_randomness(int irq, int irq_flags);
extern void get_random_bytes(void *buf, int nbytes);
+extern void get_blocking_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
extern int random_int_secret_init(void);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 5/5] crypto: add jitterentropy RNG
The CPU Jitter RNG provides a source of good entropy by collecting CPU executing time jitter. The entropy in the CPU execution time jitter is magnified by the CPU Jitter Random Number Generator. The CPU Jitter Random Number Generator uses the CPU execution timing jitter to generate a bit stream which complies with different statistical measurements that determine the bit stream is random. The CPU Jitter Random Number Generator delivers entropy which follows information theoretical requirements. Based on these studies and the implementation, the caller can assume that one bit of data extracted from the CPU Jitter Random Number Generator holds one bit of entropy. The CPU Jitter Random Number Generator provides a decentralized source of entropy, i.e. every caller can operate on a private state of the entropy pool. The RNG does not have any dependencies on any other service in the kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + 4 files changed, 925 insertions(+) create mode 100644 crypto/jitterentropy.c diff --git a/crypto/Kconfig b/crypto/Kconfig index eba55b4..717f2d7 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1478,9 +1478,19 @@ config CRYPTO_DRBG tristate default CRYPTO_DRBG_MENU if (CRYPTO_DRBG_HMAC || CRYPTO_DRBG_HASH || CRYPTO_DRBG_CTR) select CRYPTO_RNG + select CRYPTO_JITTERENTROPY endif # if CRYPTO_DRBG_MENU +config CRYPTO_JITTERENTROPY + tristate "Jitterentropy Non-Deterministic Random Number Generator" + help + The Jitterentropy RNG is a noise that is intended + to provide seed to another RNG. The RNG does not + perform any cryptographic whitening of the generated + random numbers. This Jitterentropy RNG registers with + the kernel crypto API and can be used by any caller. + config CRYPTO_USER_API tristate diff --git a/crypto/Makefile b/crypto/Makefile index 97b7d3a..2f450ef 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -94,6 +94,8 @@ obj-$(CONFIG_CRYPTO_RNG2) += rng.o obj-$(CONFIG_CRYPTO_RNG2) += krng.o obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o obj-$(CONFIG_CRYPTO_DRBG) += drbg.o +CFLAGS_jitterentropy.o = -O0 +obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c new file mode 100644 index 000..1ebe58a --- /dev/null +++ b/crypto/jitterentropy.c @@ -0,0 +1,909 @@ +/* + * Non-physical true random number generator based on timing jitter. + * + * Copyright Stephan Mueller , 2014 + * + * Design + * == + * + * See http://www.chronox.de/jent.html + * + * License + * === + * + * 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 GPL2 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 O
[PATCH v10 0/5] Seeding DRBG with more entropy
Hi, as of now, the DRBG is only seeded from get_random_bytes. In various circumstances, the nonblocking_pool behind get_random_bytes may not be fully seeded from hardware events at the time the DRBG requires to be seeded. Based on the discussion in [1], the DRBG seeding is updated such that it does not completely rely on get_random_bytes any more. The seeding approach can be characterized as follows: 1. pull buffer of size entropy + nonce from get_random_bytes 2. pull another buffer of size entropy + nonce from my Jitter RNG 3. concatenate both buffers 4. seed the DRBG with the concatenated buffer 5. trigger the async invocation of the blocking API for accessing the nonblocking pool with a buffer of size entropy 6. return the DRBG instance to the caller without waiting for the completion of step 5 7. at some point in time, the blocking API returns with a full buffer which is then used to re-seed the DRBG This way, we will get entropy during the first initialization without blocking. The patch set adds a blocking API to access the nonblocking pool to wait until the nonblocking pool is initialized. Note: the DRBG and Jitter RNG patches are against the current cryptodev-2.6 tree. The new Jitter RNG is an RNG that has large set of tests and was presented on LKML some time back. After speaking with mathematicians at NIST, that Jitter RNG approach would be acceptable from their side as a noise source. Note, I personally think that the Jitter RNG has sufficient entropy in almost all circumstances (see the massive testing I conducted on all more widely used CPUs as shown in [2]). Changes v10: * patch 01/03: use uninterruptible sleep -- this patch only works with the change from wake_up_interruptible to wake_up_all for drivers/char/random.c proposed by Herbert Xu Changes v9: * patch 01: initialize return code Changes v8: * patch 01: make get_blocking_random_bytes to return the wait_event_interruptible error code * patch 03: catch the ERESTARTSYS error code from get_blocking_random_bytes Changes v7: * patch 01: Catch ERESTARTSYS error for wait_event_interruptible * patch 03: move the cancel invocation to drbg_uninstantiate to ensure that the ->fini function pointer is not yet invoked before the cancel is completed. As the cancel operation may potentially invoke crypto operations, the cipher state must be available. * patch 04: deallocate Jitter RNG after nonblocking_pool is fully initialized. The change implies that regardless of the state of the nonblocking_pool, the Jitter RNG is used for the initial seeding in any case and only dropped for later reseeding operations. Changes v6: * patch 01: simplify patch by just adding a blocking API call to random.c as suggested by Herbert Xu. * patch 03: move the async operation into this patch: the DRBG is in control of the async work. Changes v5: * drop patch 01 and therefore drop the creation of a kernel pool * change patch 02 to use the nonblocking pool and block until the nonblocking pool is initialized or until the cancel operation is triggered. Changes v4: * Patch 02: Change get_blocking_random_bytes_cb to allow callers to call it multiple times without re-initializing the work data structure. Furthermore, only change the pointers to the output buffer and callback if work is not pending to avoid race conditions. * Patch 04: No canceling of seeding during drbg_seed as the invocation of get_blocking_random_bytes_cb can now be done repeatedly without re-initializing the work data structure. Changes v3: * Patch 01: Correct calculation of entropy count as pointed out by Herbert Xu * Patch 06: Correct a trivial coding issue in jent_entropy_init for checking JENT_EMINVARVAR reported by cppcheck Changes v2: * Use Dual BSD/GPL license in MODULE_LICENSE as suggested by Paul Bolle * Patch 05, drbg_dealloc_state: only deallocate Jitter RNG if one was instantiated in the first place. There are two main reasons why the Jitter RNG may not be allocated: either it is not available as kernel module/in vmlinuz or during init time of the Jitter RNG, the performed testing shows that the underlying hardware is not suitable for the Jitter RNG (e.g. has a too coarse timer). [1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg13891.html [2] http://www.chronox.de/jent.html Stephan Mueller (5): random: Blocking API for accessing nonblocking_pool crypto: drbg - prepare for async seeding crypto: drbg - add async seeding operation crypto: drbg - use Jitter RNG to obtain seed crypto: add jitterentropy RNG crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/drbg.c | 143 ++-- crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + drivers/char/random.c | 12 + include/crypto/drbg.h | 5 + include/linux/random.h | 1 + 8 files changed, 1059 insertions(+), 27 deletions(-) create mode 100644 cry
[PATCH v10 4/5] crypto: drbg - use Jitter RNG to obtain seed
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now the seed for the DRBG.
Written differently, the initial seed of the DRBG is now:
get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce)
If the Jitter RNG is not available, the DRBG only seeds from
get_random_bytes.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 52 ---
include/crypto/drbg.h | 1 +
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index aca8684..9284348 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1062,13 +1062,18 @@ static void drbg_async_seed(struct work_struct *work)
LIST_HEAD(seedlist);
struct drbg_state *drbg = container_of(work, struct drbg_state,
seed_work);
+ int ret;
get_blocking_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
list_add_tail(&data.list, &seedlist);
mutex_lock(&drbg->drbg_mutex);
- __drbg_seed(drbg, &seedlist, true);
+ ret = __drbg_seed(drbg, &seedlist, true);
+ if (!ret && drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
mutex_unlock(&drbg->drbg_mutex);
}
@@ -1103,10 +1108,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-drbg->seed_buf_len);
+ /* Get seed from in-kernel /dev/urandom */
get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
- drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
+
+ /* Get seed from Jitter RNG */
+ if (!drbg->jent ||
+ crypto_rng_get_bytes(drbg->jent,
+drbg->seed_buf + drbg->seed_buf_len,
+drbg->seed_buf_len)) {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len);
+ } else {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len * 2);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len * 2);
+ }
}
list_add_tail(&data1.list, &seedlist);
@@ -1131,7 +1150,7 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
* Clear the initial entropy buffer as the async call may not overwrite
* that buffer for quite some time.
*/
- memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len * 2);
if (ret)
goto out;
/*
@@ -1171,6 +1190,10 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
#endif
kzfree(drbg->seed_buf);
drbg->seed_buf = NULL;
+ if (drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
}
/*
@@ -1246,14 +1269,29 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
ret = -EFAULT;
goto err;
}
- /* ensure we have sufficient buffer space for initial seed */
+ /*
+* Ensure we have sufficient buffer space for initial seed which
+* consists of the seed from get_random_bytes and the Jitter RNG.
+*/
drbg->seed_buf_len = ((drbg->seed_buf_len + 1) / 2) * 3;
- drbg->seed_buf = kzalloc(drbg->seed_buf_len, GFP_KERNEL);
+ drbg->seed_buf = kzalloc(drbg->seed_buf_len * 2, GFP_KERNEL);
if (!drbg->seed_buf)
goto err;
INIT_WORK(&drbg->seed_work, drbg_async_seed);
+ drbg->jent = crypto_alloc_rng("jitterentropy_rng", 0, 0);
+ if(IS_ERR(drbg->jent))
+ {
+ pr_info("DRBG: cou
[PATCH v10 3/5] crypto: drbg - add async seeding operation
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the actual seeding of the DRBG.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 24
include/crypto/drbg.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 36dfece..aca8684 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1056,6 +1056,23 @@ static inline int __drbg_seed(struct drbg_state *drbg,
struct list_head *seed,
return ret;
}
+static void drbg_async_seed(struct work_struct *work)
+{
+ struct drbg_string data;
+ LIST_HEAD(seedlist);
+ struct drbg_state *drbg = container_of(work, struct drbg_state,
+ seed_work);
+
+ get_blocking_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+
+ drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
+ list_add_tail(&data.list, &seedlist);
+ mutex_lock(&drbg->drbg_mutex);
+ __drbg_seed(drbg, &seedlist, true);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ mutex_unlock(&drbg->drbg_mutex);
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1125,6 +1142,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
if (!reseed)
drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
+ /* Invoke asynchronous seeding unless DRBG is in test mode. */
+ if (!list_empty(&drbg->test_data.list) && !reseed)
+ schedule_work(&drbg->seed_work);
+
out:
return ret;
}
@@ -1231,6 +1252,8 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->seed_buf)
goto err;
+ INIT_WORK(&drbg->seed_work, drbg_async_seed);
+
return 0;
err:
@@ -1487,6 +1510,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(&drbg->seed_work);
if (drbg->d_ops)
drbg->d_ops->crypto_fini(drbg);
drbg_dealloc_state(drbg);
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index b052698..46994b2 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
/*
* Concatenation Helper and string operation helper
@@ -119,6 +120,7 @@ struct drbg_state {
bool fips_primed; /* Continuous test primed? */
unsigned char *prev;/* FIPS 140-2 continuous test value */
#endif
+ struct work_struct seed_work; /* asynchronous seeding support */
u8 *seed_buf; /* buffer holding the seed */
size_t seed_buf_len;
const struct drbg_state_ops *d_ops;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 2/5] crypto: drbg - prepare for async seeding
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for the initial seeding operation as well as by the
asynchronous seeding call. The memory must be zeroized every time the
DRBG seeding call succeeds to avoid entropy data lingering in memory.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 81 ++-
include/crypto/drbg.h | 2 ++
2 files changed, 56 insertions(+), 27 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 23d444e..36dfece 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1041,6 +1041,21 @@ static struct drbg_state_ops drbg_hash_ops = {
* Functions common for DRBG implementations
**/
+static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *seed,
+ int reseed)
+{
+ int ret = drbg->d_ops->update(drbg, seed, reseed);
+
+ if (ret)
+ return ret;
+
+ drbg->seeded = true;
+ /* 10.1.1.2 / 10.1.1.3 step 5 */
+ drbg->reseed_ctr = 1;
+
+ return ret;
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1056,8 +1071,6 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
bool reseed)
{
int ret = 0;
- unsigned char *entropy = NULL;
- size_t entropylen = 0;
struct drbg_string data1;
LIST_HEAD(seedlist);
@@ -1073,26 +1086,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- /*
-* Gather entropy equal to the security strength of the DRBG.
-* With a derivation function, a nonce is required in addition
-* to the entropy. A nonce must be at least 1/2 of the security
-* strength of the DRBG in size. Thus, entropy * nonce is 3/2
-* of the strength. The consideration of a nonce is only
-* applicable during initial seeding.
-*/
- entropylen = drbg_sec_strength(drbg->core->flags);
- if (!entropylen)
- return -EFAULT;
- if (!reseed)
- entropylen = ((entropylen + 1) / 2) * 3;
pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-entropylen);
- entropy = kzalloc(entropylen, GFP_KERNEL);
- if (!entropy)
- return -ENOMEM;
- get_random_bytes(entropy, entropylen);
- drbg_string_fill(&data1, entropy, entropylen);
+drbg->seed_buf_len);
+ get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
}
list_add_tail(&data1.list, &seedlist);
@@ -,16 +1108,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
memset(drbg->C, 0, drbg_statelen(drbg));
}
- ret = drbg->d_ops->update(drbg, &seedlist, reseed);
+ ret = __drbg_seed(drbg, &seedlist, reseed);
+
+ /*
+* Clear the initial entropy buffer as the async call may not overwrite
+* that buffer for quite some time.
+*/
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
if (ret)
goto out;
-
- drbg->seeded = true;
- /* 10.1.1.2 / 10.1.1.3 step 5 */
- drbg->reseed_ctr = 1;
+ /*
+* For all subsequent seeding calls, we only need the seed buffer
+* equal to the security strength of the DRBG. We undo the calculation
+* in drbg_alloc_state.
+*/
+ if (!reseed)
+ drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
out:
- kzfree(entropy);
return ret;
}
@@ -1143,6 +1148,8 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
drbg->prev = NULL;
drbg->fips_primed = false;
#endif
+ kzfree(drbg->seed_buf);
+ drbg->seed_buf = NULL;
}
/*
@@ -1204,6 +1211,26 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->scratchpad)
goto err;
}
+
+ /*
+* Gather entropy equal to the security strength of the DRBG.
+* With a derivation function, a nonce is required in addition
+* to the entropy. A nonce must b
Re: random: Wake up all getrandom(2) callers when pool is ready
Am Donnerstag, 21. Mai 2015, 16:19:54 schrieb Herbert Xu: Hi Herbert, >On Thu, May 21, 2015 at 09:55:17AM +0200, Stephan Mueller wrote: >> So, I will create a 2nd wait queue in random.c for uninterruptible waits, >> change the get_blocking_random_bytes back to void and use wait_event to >> wait >> for the initialization. > >Hold your horses. You don't need a second queue, you just need to >change wake_up_interruptible to wake_up. A simple change to wake_up is not working -- I already checked. But the proposed wake_up_all does the trick. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 3/5] crypto: drbg - add async seeding operation
Am Donnerstag, 21. Mai 2015, 05:44:08 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
> >> @@ -1487,6 +1514,7 @@ unlock:
> > */
> >
> > static int drbg_uninstantiate(struct drbg_state *drbg)
> > {
> >
> > + cancel_work_sync(&drbg->seed_work);
>
> This will just block until the work is done, i.e., until the
> pool is ready. It's no different to an uninterruptible sleep.
>
> So either just do an uninterruptible sleep, or allow the async
> seed to fail.
I think I found the issue: we cannot put interruptible and noninterruptible
sleeps onto the same wait queue. With my initial tests, I put the
uninterruptible sleep onto urandom_init_wait where also interruptible sleeps
are put onto.
So, I will create a 2nd wait queue in random.c for uninterruptible waits,
change the get_blocking_random_bytes back to void and use wait_event to wait
for the initialization.
>
> Cheers,
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 3/5] crypto: drbg - add async seeding operation
Am Donnerstag, 21. Mai 2015, 14:36:18 schrieb Herbert Xu: Hi Herbert, >On Thu, May 21, 2015 at 08:10:13AM +0200, Stephan Mueller wrote: >> The cancel operation is needed as otherwise my drbg context handle will be >> removed by the crypto API during the sleep. That is the whole reason why >> wait_event_interruptible is used. >> >> So, even when using an uninterruptible sleep, the crypto API has no >> knowledge about it and I have to serialize the destruction code path with >> the async callback. > >I understand. But if you use the uniterruptible version at least >you won't have to deal with bogus early returns. Thank you for pointing that out - I have seen that too. But the crux is that when using wait_event, the cancel function to serialize the destruction code path will *not* return at all, even when the async callback function completed successfully. Hence the choice for wait_event_interruptible > >The cancel by itself will *not* cause wait_event_interruptible >to return early. Somebody has to send it a signal for that to >happen. Correct. But I can only wake it up with a handle on urandom_init_wait on which the wait sleeps. That handle lives in random.c. So, to wake it up, I need another piece of code in random.c. That piece of code used to be the get_blocking_random_bytes_cancel function I offered in previous patches. As Ted mentioned, he did not want to much code in random.c for this. In addition, if I understand you correctly in previous emails, it would be acceptable to wait until the callback was triggered (and thus causing the caller module to be not unloadable for that period of time. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 3/5] crypto: drbg - add async seeding operation
Am Donnerstag, 21. Mai 2015, 05:44:08 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 20, 2015 at 10:03:45PM +0200, Stephan Mueller wrote:
> >> @@ -1487,6 +1514,7 @@ unlock:
> > */
> >
> > static int drbg_uninstantiate(struct drbg_state *drbg)
> > {
> >
> > + cancel_work_sync(&drbg->seed_work);
>
> This will just block until the work is done, i.e., until the
> pool is ready. It's no different to an uninterruptible sleep.
>
> So either just do an uninterruptible sleep, or allow the async
> seed to fail.
>
The cancel operation is needed as otherwise my drbg context handle will be
removed by the crypto API during the sleep. That is the whole reason why
wait_event_interruptible is used.
So, even when using an uninterruptible sleep, the crypto API has no knowledge
about it and I have to serialize the destruction code path with the async
callback.
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 5/5] crypto: add jitterentropy RNG
The CPU Jitter RNG provides a source of good entropy by collecting CPU executing time jitter. The entropy in the CPU execution time jitter is magnified by the CPU Jitter Random Number Generator. The CPU Jitter Random Number Generator uses the CPU execution timing jitter to generate a bit stream which complies with different statistical measurements that determine the bit stream is random. The CPU Jitter Random Number Generator delivers entropy which follows information theoretical requirements. Based on these studies and the implementation, the caller can assume that one bit of data extracted from the CPU Jitter Random Number Generator holds one bit of entropy. The CPU Jitter Random Number Generator provides a decentralized source of entropy, i.e. every caller can operate on a private state of the entropy pool. The RNG does not have any dependencies on any other service in the kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + 4 files changed, 925 insertions(+) create mode 100644 crypto/jitterentropy.c diff --git a/crypto/Kconfig b/crypto/Kconfig index eba55b4..717f2d7 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1478,9 +1478,19 @@ config CRYPTO_DRBG tristate default CRYPTO_DRBG_MENU if (CRYPTO_DRBG_HMAC || CRYPTO_DRBG_HASH || CRYPTO_DRBG_CTR) select CRYPTO_RNG + select CRYPTO_JITTERENTROPY endif # if CRYPTO_DRBG_MENU +config CRYPTO_JITTERENTROPY + tristate "Jitterentropy Non-Deterministic Random Number Generator" + help + The Jitterentropy RNG is a noise that is intended + to provide seed to another RNG. The RNG does not + perform any cryptographic whitening of the generated + random numbers. This Jitterentropy RNG registers with + the kernel crypto API and can be used by any caller. + config CRYPTO_USER_API tristate diff --git a/crypto/Makefile b/crypto/Makefile index 97b7d3a..2f450ef 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -94,6 +94,8 @@ obj-$(CONFIG_CRYPTO_RNG2) += rng.o obj-$(CONFIG_CRYPTO_RNG2) += krng.o obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o obj-$(CONFIG_CRYPTO_DRBG) += drbg.o +CFLAGS_jitterentropy.o = -O0 +obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c new file mode 100644 index 000..1ebe58a --- /dev/null +++ b/crypto/jitterentropy.c @@ -0,0 +1,909 @@ +/* + * Non-physical true random number generator based on timing jitter. + * + * Copyright Stephan Mueller , 2014 + * + * Design + * == + * + * See http://www.chronox.de/jent.html + * + * License + * === + * + * 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 GPL2 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 O
[PATCH v9 1/5] random: Blocking API for accessing nonblocking_pool
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 20
include/linux/random.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..9815a26 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1245,6 +1245,26 @@ void get_random_bytes(void *buf, int nbytes)
EXPORT_SYMBOL(get_random_bytes);
/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+int get_blocking_random_bytes(void *buf, int nbytes)
+{
+ int rc = 0;
+
+ if (unlikely(nonblocking_pool.initialized == 0))
+ rc = wait_event_interruptible(urandom_init_wait,
+ nonblocking_pool.initialized);
+ if (rc)
+ return rc;
+
+ extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL(get_blocking_random_bytes);
+
+/*
* This function will use the architecture-specific hardware random
* number generator if it is available. The arch-specific hw RNG will
* almost certainly be faster than what we can do in software, but it
diff --git a/include/linux/random.h b/include/linux/random.h
index b05856e..7d0d72f 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -14,6 +14,7 @@ extern void add_input_randomness(unsigned int type, unsigned
int code,
extern void add_interrupt_randomness(int irq, int irq_flags);
extern void get_random_bytes(void *buf, int nbytes);
+extern int get_blocking_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
extern int random_int_secret_init(void);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/5] crypto: drbg - add async seeding operation
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the actual seeding of the DRBG.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 28
include/crypto/drbg.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 36dfece..563e5e9 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1056,6 +1056,27 @@ static inline int __drbg_seed(struct drbg_state *drbg,
struct list_head *seed,
return ret;
}
+static void drbg_async_seed(struct work_struct *work)
+{
+ struct drbg_string data;
+ LIST_HEAD(seedlist);
+ struct drbg_state *drbg = container_of(work, struct drbg_state,
+ seed_work);
+ int ret;
+
+ do {
+ ret = get_blocking_random_bytes(drbg->seed_buf,
+ drbg->seed_buf_len);
+ } while (ret == -ERESTARTSYS);
+
+ drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
+ list_add_tail(&data.list, &seedlist);
+ mutex_lock(&drbg->drbg_mutex);
+ __drbg_seed(drbg, &seedlist, true);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ mutex_unlock(&drbg->drbg_mutex);
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1125,6 +1146,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
if (!reseed)
drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
+ /* Invoke asynchronous seeding unless DRBG is in test mode. */
+ if (!list_empty(&drbg->test_data.list) && !reseed)
+ schedule_work(&drbg->seed_work);
+
out:
return ret;
}
@@ -1231,6 +1256,8 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->seed_buf)
goto err;
+ INIT_WORK(&drbg->seed_work, drbg_async_seed);
+
return 0;
err:
@@ -1487,6 +1514,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(&drbg->seed_work);
if (drbg->d_ops)
drbg->d_ops->crypto_fini(drbg);
drbg_dealloc_state(drbg);
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index b052698..46994b2 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
/*
* Concatenation Helper and string operation helper
@@ -119,6 +120,7 @@ struct drbg_state {
bool fips_primed; /* Continuous test primed? */
unsigned char *prev;/* FIPS 140-2 continuous test value */
#endif
+ struct work_struct seed_work; /* asynchronous seeding support */
u8 *seed_buf; /* buffer holding the seed */
size_t seed_buf_len;
const struct drbg_state_ops *d_ops;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 0/5] Seeding DRBG with more entropy
Hi, as of now, the DRBG is only seeded from get_random_bytes. In various circumstances, the nonblocking_pool behind get_random_bytes may not be fully seeded from hardware events at the time the DRBG requires to be seeded. Based on the discussion in [1], the DRBG seeding is updated such that it does not completely rely on get_random_bytes any more. The seeding approach can be characterized as follows: 1. pull buffer of size entropy + nonce from get_random_bytes 2. pull another buffer of size entropy + nonce from my Jitter RNG 3. concatenate both buffers 4. seed the DRBG with the concatenated buffer 5. trigger the async invocation of the blocking API for accessing the nonblocking pool with a buffer of size entropy 6. return the DRBG instance to the caller without waiting for the completion of step 5 7. at some point in time, the blocking API returns with a full buffer which is then used to re-seed the DRBG This way, we will get entropy during the first initialization without blocking. The patch set adds a blocking API to access the nonblocking pool to wait until the nonblocking pool is initialized. Note: the DRBG and Jitter RNG patches are against the current cryptodev-2.6 tree. The new Jitter RNG is an RNG that has large set of tests and was presented on LKML some time back. After speaking with mathematicians at NIST, that Jitter RNG approach would be acceptable from their side as a noise source. Note, I personally think that the Jitter RNG has sufficient entropy in almost all circumstances (see the massive testing I conducted on all more widely used CPUs as shown in [2]). Changes v9: * patch 01: initialize return code Changes v8: * patch 01: make get_blocking_random_bytes to return the wait_event_interruptible error code * patch 03: catch the ERESTARTSYS error code from get_blocking_random_bytes Changes v7: * patch 01: Catch ERESTARTSYS error for wait_event_interruptible * patch 03: move the cancel invocation to drbg_uninstantiate to ensure that the ->fini function pointer is not yet invoked before the cancel is completed. As the cancel operation may potentially invoke crypto operations, the cipher state must be available. * patch 04: deallocate Jitter RNG after nonblocking_pool is fully initialized. The change implies that regardless of the state of the nonblocking_pool, the Jitter RNG is used for the initial seeding in any case and only dropped for later reseeding operations. Changes v6: * patch 01: simplify patch by just adding a blocking API call to random.c as suggested by Herbert Xu. * patch 03: move the async operation into this patch: the DRBG is in control of the async work. Changes v5: * drop patch 01 and therefore drop the creation of a kernel pool * change patch 02 to use the nonblocking pool and block until the nonblocking pool is initialized or until the cancel operation is triggered. Changes v4: * Patch 02: Change get_blocking_random_bytes_cb to allow callers to call it multiple times without re-initializing the work data structure. Furthermore, only change the pointers to the output buffer and callback if work is not pending to avoid race conditions. * Patch 04: No canceling of seeding during drbg_seed as the invocation of get_blocking_random_bytes_cb can now be done repeatedly without re-initializing the work data structure. Changes v3: * Patch 01: Correct calculation of entropy count as pointed out by Herbert Xu * Patch 06: Correct a trivial coding issue in jent_entropy_init for checking JENT_EMINVARVAR reported by cppcheck Changes v2: * Use Dual BSD/GPL license in MODULE_LICENSE as suggested by Paul Bolle * Patch 05, drbg_dealloc_state: only deallocate Jitter RNG if one was instantiated in the first place. There are two main reasons why the Jitter RNG may not be allocated: either it is not available as kernel module/in vmlinuz or during init time of the Jitter RNG, the performed testing shows that the underlying hardware is not suitable for the Jitter RNG (e.g. has a too coarse timer). [1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg13891.html [2] http://www.chronox.de/jent.html Stephan Mueller (5): random: Blocking API for accessing nonblocking_pool crypto: drbg - prepare for async seeding crypto: drbg - add async seeding operation crypto: drbg - use Jitter RNG to obtain seed crypto: add jitterentropy RNG crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/drbg.c | 146 ++-- crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + drivers/char/random.c | 20 ++ include/crypto/drbg.h | 5 + include/linux/random.h | 1 + 8 files changed, 1070 insertions(+), 27 deletions(-) create mode 100644 crypto/jitterentropy.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo
[PATCH v9 2/5] crypto: drbg - prepare for async seeding
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for the initial seeding operation as well as by the
asynchronous seeding call. The memory must be zeroized every time the
DRBG seeding call succeeds to avoid entropy data lingering in memory.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 81 ++-
include/crypto/drbg.h | 2 ++
2 files changed, 56 insertions(+), 27 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 23d444e..36dfece 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1041,6 +1041,21 @@ static struct drbg_state_ops drbg_hash_ops = {
* Functions common for DRBG implementations
**/
+static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *seed,
+ int reseed)
+{
+ int ret = drbg->d_ops->update(drbg, seed, reseed);
+
+ if (ret)
+ return ret;
+
+ drbg->seeded = true;
+ /* 10.1.1.2 / 10.1.1.3 step 5 */
+ drbg->reseed_ctr = 1;
+
+ return ret;
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1056,8 +1071,6 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
bool reseed)
{
int ret = 0;
- unsigned char *entropy = NULL;
- size_t entropylen = 0;
struct drbg_string data1;
LIST_HEAD(seedlist);
@@ -1073,26 +1086,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- /*
-* Gather entropy equal to the security strength of the DRBG.
-* With a derivation function, a nonce is required in addition
-* to the entropy. A nonce must be at least 1/2 of the security
-* strength of the DRBG in size. Thus, entropy * nonce is 3/2
-* of the strength. The consideration of a nonce is only
-* applicable during initial seeding.
-*/
- entropylen = drbg_sec_strength(drbg->core->flags);
- if (!entropylen)
- return -EFAULT;
- if (!reseed)
- entropylen = ((entropylen + 1) / 2) * 3;
pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-entropylen);
- entropy = kzalloc(entropylen, GFP_KERNEL);
- if (!entropy)
- return -ENOMEM;
- get_random_bytes(entropy, entropylen);
- drbg_string_fill(&data1, entropy, entropylen);
+drbg->seed_buf_len);
+ get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
}
list_add_tail(&data1.list, &seedlist);
@@ -,16 +1108,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
memset(drbg->C, 0, drbg_statelen(drbg));
}
- ret = drbg->d_ops->update(drbg, &seedlist, reseed);
+ ret = __drbg_seed(drbg, &seedlist, reseed);
+
+ /*
+* Clear the initial entropy buffer as the async call may not overwrite
+* that buffer for quite some time.
+*/
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
if (ret)
goto out;
-
- drbg->seeded = true;
- /* 10.1.1.2 / 10.1.1.3 step 5 */
- drbg->reseed_ctr = 1;
+ /*
+* For all subsequent seeding calls, we only need the seed buffer
+* equal to the security strength of the DRBG. We undo the calculation
+* in drbg_alloc_state.
+*/
+ if (!reseed)
+ drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
out:
- kzfree(entropy);
return ret;
}
@@ -1143,6 +1148,8 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
drbg->prev = NULL;
drbg->fips_primed = false;
#endif
+ kzfree(drbg->seed_buf);
+ drbg->seed_buf = NULL;
}
/*
@@ -1204,6 +1211,26 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->scratchpad)
goto err;
}
+
+ /*
+* Gather entropy equal to the security strength of the DRBG.
+* With a derivation function, a nonce is required in addition
+* to the entropy. A nonce must b
[PATCH v9 4/5] crypto: drbg - use Jitter RNG to obtain seed
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now the seed for the DRBG.
Written differently, the initial seed of the DRBG is now:
get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce)
If the Jitter RNG is not available, the DRBG only seeds from
get_random_bytes.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 51 ---
include/crypto/drbg.h | 1 +
2 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 563e5e9..e9fd60d 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1072,7 +1072,11 @@ static void drbg_async_seed(struct work_struct *work)
drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
list_add_tail(&data.list, &seedlist);
mutex_lock(&drbg->drbg_mutex);
- __drbg_seed(drbg, &seedlist, true);
+ ret = __drbg_seed(drbg, &seedlist, true);
+ if (!ret && drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
mutex_unlock(&drbg->drbg_mutex);
}
@@ -1107,10 +,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-drbg->seed_buf_len);
+ /* Get seed from in-kernel /dev/urandom */
get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
- drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
+
+ /* Get seed from Jitter RNG */
+ if (!drbg->jent ||
+ crypto_rng_get_bytes(drbg->jent,
+drbg->seed_buf + drbg->seed_buf_len,
+drbg->seed_buf_len)) {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len);
+ } else {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len * 2);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len * 2);
+ }
}
list_add_tail(&data1.list, &seedlist);
@@ -1135,7 +1153,7 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
* Clear the initial entropy buffer as the async call may not overwrite
* that buffer for quite some time.
*/
- memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len * 2);
if (ret)
goto out;
/*
@@ -1175,6 +1193,10 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
#endif
kzfree(drbg->seed_buf);
drbg->seed_buf = NULL;
+ if (drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
}
/*
@@ -1250,14 +1272,29 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
ret = -EFAULT;
goto err;
}
- /* ensure we have sufficient buffer space for initial seed */
+ /*
+* Ensure we have sufficient buffer space for initial seed which
+* consists of the seed from get_random_bytes and the Jitter RNG.
+*/
drbg->seed_buf_len = ((drbg->seed_buf_len + 1) / 2) * 3;
- drbg->seed_buf = kzalloc(drbg->seed_buf_len, GFP_KERNEL);
+ drbg->seed_buf = kzalloc(drbg->seed_buf_len * 2, GFP_KERNEL);
if (!drbg->seed_buf)
goto err;
INIT_WORK(&drbg->seed_work, drbg_async_seed);
+ drbg->jent = crypto_alloc_rng("jitterentropy_rng", 0, 0);
+ if(IS_ERR(drbg->jent))
+ {
+ pr_info("DRBG: could not allocate Jitter RNG handle for
seeding\n");
+ /*
+* As the Jitter RNG is a module that may not be present, we
+* continue with the operation and do not fully tie the DRBG
+* to the Jitter RNG.
+
Re: [PATCH v8 1/5] random: Blocking API for accessing nonblocking_pool
Am Mittwoch, 20. Mai 2015, 21:44:46 schrieb Stephan Mueller:
Hi,
> +int get_blocking_random_bytes(void *buf, int nbytes)
> +{
> + int rc;
Sorry, I should be more carefully here: the rc should be initialized to 0 :-(
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 5/5] crypto: add jitterentropy RNG
The CPU Jitter RNG provides a source of good entropy by collecting CPU executing time jitter. The entropy in the CPU execution time jitter is magnified by the CPU Jitter Random Number Generator. The CPU Jitter Random Number Generator uses the CPU execution timing jitter to generate a bit stream which complies with different statistical measurements that determine the bit stream is random. The CPU Jitter Random Number Generator delivers entropy which follows information theoretical requirements. Based on these studies and the implementation, the caller can assume that one bit of data extracted from the CPU Jitter Random Number Generator holds one bit of entropy. The CPU Jitter Random Number Generator provides a decentralized source of entropy, i.e. every caller can operate on a private state of the entropy pool. The RNG does not have any dependencies on any other service in the kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + 4 files changed, 925 insertions(+) create mode 100644 crypto/jitterentropy.c diff --git a/crypto/Kconfig b/crypto/Kconfig index eba55b4..717f2d7 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1478,9 +1478,19 @@ config CRYPTO_DRBG tristate default CRYPTO_DRBG_MENU if (CRYPTO_DRBG_HMAC || CRYPTO_DRBG_HASH || CRYPTO_DRBG_CTR) select CRYPTO_RNG + select CRYPTO_JITTERENTROPY endif # if CRYPTO_DRBG_MENU +config CRYPTO_JITTERENTROPY + tristate "Jitterentropy Non-Deterministic Random Number Generator" + help + The Jitterentropy RNG is a noise that is intended + to provide seed to another RNG. The RNG does not + perform any cryptographic whitening of the generated + random numbers. This Jitterentropy RNG registers with + the kernel crypto API and can be used by any caller. + config CRYPTO_USER_API tristate diff --git a/crypto/Makefile b/crypto/Makefile index 97b7d3a..2f450ef 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -94,6 +94,8 @@ obj-$(CONFIG_CRYPTO_RNG2) += rng.o obj-$(CONFIG_CRYPTO_RNG2) += krng.o obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o obj-$(CONFIG_CRYPTO_DRBG) += drbg.o +CFLAGS_jitterentropy.o = -O0 +obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c new file mode 100644 index 000..1ebe58a --- /dev/null +++ b/crypto/jitterentropy.c @@ -0,0 +1,909 @@ +/* + * Non-physical true random number generator based on timing jitter. + * + * Copyright Stephan Mueller , 2014 + * + * Design + * == + * + * See http://www.chronox.de/jent.html + * + * License + * === + * + * 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 GPL2 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 O
[PATCH v8 4/5] crypto: drbg - use Jitter RNG to obtain seed
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now the seed for the DRBG.
Written differently, the initial seed of the DRBG is now:
get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce)
If the Jitter RNG is not available, the DRBG only seeds from
get_random_bytes.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 51 ---
include/crypto/drbg.h | 1 +
2 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 4e54973..21d93ce 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1072,7 +1072,11 @@ static void drbg_async_seed(struct work_struct *work)
drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
list_add_tail(&data.list, &seedlist);
mutex_lock(&drbg->drbg_mutex);
- __drbg_seed(drbg, &seedlist, true);
+ ret = __drbg_seed(drbg, &seedlist, true);
+ if (!ret && drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
mutex_unlock(&drbg->drbg_mutex);
}
@@ -1107,10 +,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-drbg->seed_buf_len);
+ /* Get seed from in-kernel /dev/urandom */
get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
- drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
+
+ /* Get seed from Jitter RNG */
+ if (!drbg->jent ||
+ crypto_rng_get_bytes(drbg->jent,
+drbg->seed_buf + drbg->seed_buf_len,
+drbg->seed_buf_len)) {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len);
+ } else {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len * 2);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len * 2);
+ }
}
list_add_tail(&data1.list, &seedlist);
@@ -1135,7 +1153,7 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
* Clear the initial entropy buffer as the async call may not overwrite
* that buffer for quite some time.
*/
- memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len * 2);
if (ret)
goto out;
/*
@@ -1175,6 +1193,10 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
#endif
kzfree(drbg->seed_buf);
drbg->seed_buf = NULL;
+ if (drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
}
/*
@@ -1250,14 +1272,29 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
ret = -EFAULT;
goto err;
}
- /* ensure we have sufficient buffer space for initial seed */
+ /*
+* Ensure we have sufficient buffer space for initial seed which
+* consists of the seed from get_random_bytes and the Jitter RNG.
+*/
drbg->seed_buf_len = ((drbg->seed_buf_len + 1) / 2) * 3;
- drbg->seed_buf = kzalloc(drbg->seed_buf_len, GFP_KERNEL);
+ drbg->seed_buf = kzalloc(drbg->seed_buf_len * 2, GFP_KERNEL);
if (!drbg->seed_buf)
goto err;
INIT_WORK(&drbg->seed_work, drbg_async_seed);
+ drbg->jent = crypto_alloc_rng("jitterentropy_rng", 0, 0);
+ if(IS_ERR(drbg->jent))
+ {
+ pr_info("DRBG: could not allocate Jitter RNG handle for
seeding\n");
+ /*
+* As the Jitter RNG is a module that may not be present, we
+* continue with the operation and do not fully tie the DRBG
+* to the Jitter RNG.
+
[PATCH v8 0/5] Seeding DRBG with more entropy
Hi, as of now, the DRBG is only seeded from get_random_bytes. In various circumstances, the nonblocking_pool behind get_random_bytes may not be fully seeded from hardware events at the time the DRBG requires to be seeded. Based on the discussion in [1], the DRBG seeding is updated such that it does not completely rely on get_random_bytes any more. The seeding approach can be characterized as follows: 1. pull buffer of size entropy + nonce from get_random_bytes 2. pull another buffer of size entropy + nonce from my Jitter RNG 3. concatenate both buffers 4. seed the DRBG with the concatenated buffer 5. trigger the async invocation of the blocking API for accessing the nonblocking pool with a buffer of size entropy 6. return the DRBG instance to the caller without waiting for the completion of step 5 7. at some point in time, the blocking API returns with a full buffer which is then used to re-seed the DRBG This way, we will get entropy during the first initialization without blocking. The patch set adds a blocking API to access the nonblocking pool to wait until the nonblocking pool is initialized. Note: the DRBG and Jitter RNG patches are against the current cryptodev-2.6 tree. The new Jitter RNG is an RNG that has large set of tests and was presented on LKML some time back. After speaking with mathematicians at NIST, that Jitter RNG approach would be acceptable from their side as a noise source. Note, I personally think that the Jitter RNG has sufficient entropy in almost all circumstances (see the massive testing I conducted on all more widely used CPUs as shown in [2]). Changes v8: * patch 01: make get_blocking_random_bytes to return the wait_event_interruptible error code * patch 03: catch the ERESTARTSYS error code from get_blocking_random_bytes Changes v7: * patch 01: Catch ERESTARTSYS error for wait_event_interruptible * patch 03: move the cancel invocation to drbg_uninstantiate to ensure that the ->fini function pointer is not yet invoked before the cancel is completed. As the cancel operation may potentially invoke crypto operations, the cipher state must be available. * patch 04: deallocate Jitter RNG after nonblocking_pool is fully initialized. The change implies that regardless of the state of the nonblocking_pool, the Jitter RNG is used for the initial seeding in any case and only dropped for later reseeding operations. Changes v6: * patch 01: simplify patch by just adding a blocking API call to random.c as suggested by Herbert Xu. * patch 03: move the async operation into this patch: the DRBG is in control of the async work. Changes v5: * drop patch 01 and therefore drop the creation of a kernel pool * change patch 02 to use the nonblocking pool and block until the nonblocking pool is initialized or until the cancel operation is triggered. Changes v4: * Patch 02: Change get_blocking_random_bytes_cb to allow callers to call it multiple times without re-initializing the work data structure. Furthermore, only change the pointers to the output buffer and callback if work is not pending to avoid race conditions. * Patch 04: No canceling of seeding during drbg_seed as the invocation of get_blocking_random_bytes_cb can now be done repeatedly without re-initializing the work data structure. Changes v3: * Patch 01: Correct calculation of entropy count as pointed out by Herbert Xu * Patch 06: Correct a trivial coding issue in jent_entropy_init for checking JENT_EMINVARVAR reported by cppcheck Changes v2: * Use Dual BSD/GPL license in MODULE_LICENSE as suggested by Paul Bolle * Patch 05, drbg_dealloc_state: only deallocate Jitter RNG if one was instantiated in the first place. There are two main reasons why the Jitter RNG may not be allocated: either it is not available as kernel module/in vmlinuz or during init time of the Jitter RNG, the performed testing shows that the underlying hardware is not suitable for the Jitter RNG (e.g. has a too coarse timer). [1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg13891.html [2] http://www.chronox.de/jent.html Stephan Mueller (5): random: Blocking API for accessing nonblocking_pool crypto: drbg - prepare for async seeding crypto: drbg - add async seeding operation crypto: drbg - use Jitter RNG to obtain seed crypto: add jitterentropy RNG crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/drbg.c | 146 ++-- crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + drivers/char/random.c | 20 ++ include/crypto/drbg.h | 5 + include/linux/random.h | 1 + 8 files changed, 1070 insertions(+), 27 deletions(-) create mode 100644 crypto/jitterentropy.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Pl
[PATCH v8 3/5] crypto: drbg - add async seeding operation
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the actual seeding of the DRBG.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 28
include/crypto/drbg.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 36dfece..4e54973 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1056,6 +1056,27 @@ static inline int __drbg_seed(struct drbg_state *drbg,
struct list_head *seed,
return ret;
}
+static void drbg_async_seed(struct work_struct *work)
+{
+ struct drbg_string data;
+ LIST_HEAD(seedlist);
+ struct drbg_state *drbg = container_of(work, struct drbg_state,
+ seed_work);
+ int ret;
+
+ do {
+ ret = get_blocking_random_bytes(drbg->seed_buf,
+ drbg->seed_buf_len);
+ } while (ret == -ERESTARTSYS);
+
+ drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
+ list_add_tail(&data.list, &seedlist);
+ mutex_lock(&drbg->drbg_mutex);
+ __drbg_seed(drbg, &seedlist, true);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ mutex_unlock(&drbg->drbg_mutex);
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1125,6 +1146,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
if (!reseed)
drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
+ /* Invoke asynchronous seeding unless DRBG is in test mode. */
+ if (!list_empty(&drbg->test_data.list) && !reseed)
+ schedule_work(&drbg->seed_work);
+
out:
return ret;
}
@@ -1231,6 +1256,8 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->seed_buf)
goto err;
+ INIT_WORK(&drbg->seed_work, drbg_async_seed);
+
return 0;
err:
@@ -1487,6 +1514,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(&drbg->seed_work);
if (drbg->d_ops)
drbg->d_ops->crypto_fini(drbg);
drbg_dealloc_state(drbg);
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index b052698..46994b2 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
/*
* Concatenation Helper and string operation helper
@@ -119,6 +120,7 @@ struct drbg_state {
bool fips_primed; /* Continuous test primed? */
unsigned char *prev;/* FIPS 140-2 continuous test value */
#endif
+ struct work_struct seed_work; /* asynchronous seeding support */
u8 *seed_buf; /* buffer holding the seed */
size_t seed_buf_len;
const struct drbg_state_ops *d_ops;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 1/5] random: Blocking API for accessing nonblocking_pool
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 20
include/linux/random.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..9815a26 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1245,6 +1245,26 @@ void get_random_bytes(void *buf, int nbytes)
EXPORT_SYMBOL(get_random_bytes);
/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+int get_blocking_random_bytes(void *buf, int nbytes)
+{
+ int rc;
+
+ if (unlikely(nonblocking_pool.initialized == 0))
+ rc = wait_event_interruptible(urandom_init_wait,
+ nonblocking_pool.initialized);
+ if (rc)
+ return rc;
+
+ extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL(get_blocking_random_bytes);
+
+/*
* This function will use the architecture-specific hardware random
* number generator if it is available. The arch-specific hw RNG will
* almost certainly be faster than what we can do in software, but it
diff --git a/include/linux/random.h b/include/linux/random.h
index b05856e..7d0d72f 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -14,6 +14,7 @@ extern void add_input_randomness(unsigned int type, unsigned
int code,
extern void add_interrupt_randomness(int irq, int irq_flags);
extern void get_random_bytes(void *buf, int nbytes);
+extern int get_blocking_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
extern int random_int_secret_init(void);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 2/5] crypto: drbg - prepare for async seeding
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for the initial seeding operation as well as by the
asynchronous seeding call. The memory must be zeroized every time the
DRBG seeding call succeeds to avoid entropy data lingering in memory.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 81 ++-
include/crypto/drbg.h | 2 ++
2 files changed, 56 insertions(+), 27 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 23d444e..36dfece 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1041,6 +1041,21 @@ static struct drbg_state_ops drbg_hash_ops = {
* Functions common for DRBG implementations
**/
+static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *seed,
+ int reseed)
+{
+ int ret = drbg->d_ops->update(drbg, seed, reseed);
+
+ if (ret)
+ return ret;
+
+ drbg->seeded = true;
+ /* 10.1.1.2 / 10.1.1.3 step 5 */
+ drbg->reseed_ctr = 1;
+
+ return ret;
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1056,8 +1071,6 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
bool reseed)
{
int ret = 0;
- unsigned char *entropy = NULL;
- size_t entropylen = 0;
struct drbg_string data1;
LIST_HEAD(seedlist);
@@ -1073,26 +1086,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- /*
-* Gather entropy equal to the security strength of the DRBG.
-* With a derivation function, a nonce is required in addition
-* to the entropy. A nonce must be at least 1/2 of the security
-* strength of the DRBG in size. Thus, entropy * nonce is 3/2
-* of the strength. The consideration of a nonce is only
-* applicable during initial seeding.
-*/
- entropylen = drbg_sec_strength(drbg->core->flags);
- if (!entropylen)
- return -EFAULT;
- if (!reseed)
- entropylen = ((entropylen + 1) / 2) * 3;
pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-entropylen);
- entropy = kzalloc(entropylen, GFP_KERNEL);
- if (!entropy)
- return -ENOMEM;
- get_random_bytes(entropy, entropylen);
- drbg_string_fill(&data1, entropy, entropylen);
+drbg->seed_buf_len);
+ get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
}
list_add_tail(&data1.list, &seedlist);
@@ -,16 +1108,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
memset(drbg->C, 0, drbg_statelen(drbg));
}
- ret = drbg->d_ops->update(drbg, &seedlist, reseed);
+ ret = __drbg_seed(drbg, &seedlist, reseed);
+
+ /*
+* Clear the initial entropy buffer as the async call may not overwrite
+* that buffer for quite some time.
+*/
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
if (ret)
goto out;
-
- drbg->seeded = true;
- /* 10.1.1.2 / 10.1.1.3 step 5 */
- drbg->reseed_ctr = 1;
+ /*
+* For all subsequent seeding calls, we only need the seed buffer
+* equal to the security strength of the DRBG. We undo the calculation
+* in drbg_alloc_state.
+*/
+ if (!reseed)
+ drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
out:
- kzfree(entropy);
return ret;
}
@@ -1143,6 +1148,8 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
drbg->prev = NULL;
drbg->fips_primed = false;
#endif
+ kzfree(drbg->seed_buf);
+ drbg->seed_buf = NULL;
}
/*
@@ -1204,6 +1211,26 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->scratchpad)
goto err;
}
+
+ /*
+* Gather entropy equal to the security strength of the DRBG.
+* With a derivation function, a nonce is required in addition
+* to the entropy. A nonce must b
Re: [PATCH v7 1/5] random: Blocking API for accessing nonblocking_pool
Am Mittwoch, 20. Mai 2015, 20:49:45 schrieb Stephan Mueller: Hi Herbert, > > This is just a convoluted way of doing an uninterruptible sleep. > > Either make it uninterruptible or allow the function to return > > an error. > > Sorry, I overlooked the availability of wait_event. I was looking for it > initially, but missed it. I will fix it right away. After checking a bit more, I see that an uninterruptible sleep cannot be canceled with cancel_work_sync. Therefore, replacing it with wait_event does not work. Thus, go get an uninterruptible sleep which yet can be canceled seems to require wait_event_interruptible together with the check for ERESTARTSYS. Nonetheless, I move the loop out to the DRBG code as requested. -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/5] random: Blocking API for accessing nonblocking_pool
Am Donnerstag, 21. Mai 2015, 02:45:35 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 20, 2015 at 07:44:39PM +0200, Stephan Mueller wrote:
> > + if (unlikely(nonblocking_pool.initialized == 0)) {
> > + do {
> > + rc = wait_event_interruptible(urandom_init_wait,
> > + nonblocking_pool.initialized);
> > + } while (rc == -ERESTARTSYS);
>
> This is just a convoluted way of doing an uninterruptible sleep.
> Either make it uninterruptible or allow the function to return
> an error.
Sorry, I overlooked the availability of wait_event. I was looking for it
initially, but missed it. I will fix it right away.
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/5] crypto: drbg - prepare for async seeding
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for the initial seeding operation as well as by the
asynchronous seeding call. The memory must be zeroized every time the
DRBG seeding call succeeds to avoid entropy data lingering in memory.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 81 ++-
include/crypto/drbg.h | 2 ++
2 files changed, 56 insertions(+), 27 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 23d444e..36dfece 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1041,6 +1041,21 @@ static struct drbg_state_ops drbg_hash_ops = {
* Functions common for DRBG implementations
**/
+static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *seed,
+ int reseed)
+{
+ int ret = drbg->d_ops->update(drbg, seed, reseed);
+
+ if (ret)
+ return ret;
+
+ drbg->seeded = true;
+ /* 10.1.1.2 / 10.1.1.3 step 5 */
+ drbg->reseed_ctr = 1;
+
+ return ret;
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1056,8 +1071,6 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
bool reseed)
{
int ret = 0;
- unsigned char *entropy = NULL;
- size_t entropylen = 0;
struct drbg_string data1;
LIST_HEAD(seedlist);
@@ -1073,26 +1086,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- /*
-* Gather entropy equal to the security strength of the DRBG.
-* With a derivation function, a nonce is required in addition
-* to the entropy. A nonce must be at least 1/2 of the security
-* strength of the DRBG in size. Thus, entropy * nonce is 3/2
-* of the strength. The consideration of a nonce is only
-* applicable during initial seeding.
-*/
- entropylen = drbg_sec_strength(drbg->core->flags);
- if (!entropylen)
- return -EFAULT;
- if (!reseed)
- entropylen = ((entropylen + 1) / 2) * 3;
pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-entropylen);
- entropy = kzalloc(entropylen, GFP_KERNEL);
- if (!entropy)
- return -ENOMEM;
- get_random_bytes(entropy, entropylen);
- drbg_string_fill(&data1, entropy, entropylen);
+drbg->seed_buf_len);
+ get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
}
list_add_tail(&data1.list, &seedlist);
@@ -,16 +1108,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
memset(drbg->C, 0, drbg_statelen(drbg));
}
- ret = drbg->d_ops->update(drbg, &seedlist, reseed);
+ ret = __drbg_seed(drbg, &seedlist, reseed);
+
+ /*
+* Clear the initial entropy buffer as the async call may not overwrite
+* that buffer for quite some time.
+*/
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
if (ret)
goto out;
-
- drbg->seeded = true;
- /* 10.1.1.2 / 10.1.1.3 step 5 */
- drbg->reseed_ctr = 1;
+ /*
+* For all subsequent seeding calls, we only need the seed buffer
+* equal to the security strength of the DRBG. We undo the calculation
+* in drbg_alloc_state.
+*/
+ if (!reseed)
+ drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
out:
- kzfree(entropy);
return ret;
}
@@ -1143,6 +1148,8 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
drbg->prev = NULL;
drbg->fips_primed = false;
#endif
+ kzfree(drbg->seed_buf);
+ drbg->seed_buf = NULL;
}
/*
@@ -1204,6 +1211,26 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->scratchpad)
goto err;
}
+
+ /*
+* Gather entropy equal to the security strength of the DRBG.
+* With a derivation function, a nonce is required in addition
+* to the entropy. A nonce must b
[PATCH v7 1/5] random: Blocking API for accessing nonblocking_pool
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 18 ++
include/linux/random.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..3d1c027 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1245,6 +1245,24 @@ void get_random_bytes(void *buf, int nbytes)
EXPORT_SYMBOL(get_random_bytes);
/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+void get_blocking_random_bytes(void *buf, int nbytes)
+{
+ int rc;
+
+ if (unlikely(nonblocking_pool.initialized == 0)) {
+ do {
+ rc = wait_event_interruptible(urandom_init_wait,
+ nonblocking_pool.initialized);
+ } while (rc == -ERESTARTSYS);
+ }
+ extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
+}
+EXPORT_SYMBOL(get_blocking_random_bytes);
+
+/*
* This function will use the architecture-specific hardware random
* number generator if it is available. The arch-specific hw RNG will
* almost certainly be faster than what we can do in software, but it
diff --git a/include/linux/random.h b/include/linux/random.h
index b05856e..796267d 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -14,6 +14,7 @@ extern void add_input_randomness(unsigned int type, unsigned
int code,
extern void add_interrupt_randomness(int irq, int irq_flags);
extern void get_random_bytes(void *buf, int nbytes);
+extern void get_blocking_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
extern int random_int_secret_init(void);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 4/5] crypto: drbg - use Jitter RNG to obtain seed
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now the seed for the DRBG.
Written differently, the initial seed of the DRBG is now:
get_random_bytes(entropy/nonce) || jitterentropy (entropy/nonce)
If the Jitter RNG is not available, the DRBG only seeds from
get_random_bytes.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 52 ---
include/crypto/drbg.h | 1 +
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index aca8684..9284348 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1062,13 +1062,18 @@ static void drbg_async_seed(struct work_struct *work)
LIST_HEAD(seedlist);
struct drbg_state *drbg = container_of(work, struct drbg_state,
seed_work);
+ int ret;
get_blocking_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
list_add_tail(&data.list, &seedlist);
mutex_lock(&drbg->drbg_mutex);
- __drbg_seed(drbg, &seedlist, true);
+ ret = __drbg_seed(drbg, &seedlist, true);
+ if (!ret && drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
mutex_unlock(&drbg->drbg_mutex);
}
@@ -1103,10 +1108,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-drbg->seed_buf_len);
+ /* Get seed from in-kernel /dev/urandom */
get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
- drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
+
+ /* Get seed from Jitter RNG */
+ if (!drbg->jent ||
+ crypto_rng_get_bytes(drbg->jent,
+drbg->seed_buf + drbg->seed_buf_len,
+drbg->seed_buf_len)) {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len);
+ } else {
+ drbg_string_fill(&data1, drbg->seed_buf,
+drbg->seed_buf_len * 2);
+ pr_devel("DRBG: (re)seeding with %zu bytes of
entropy\n",
+drbg->seed_buf_len * 2);
+ }
}
list_add_tail(&data1.list, &seedlist);
@@ -1131,7 +1150,7 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
* Clear the initial entropy buffer as the async call may not overwrite
* that buffer for quite some time.
*/
- memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len * 2);
if (ret)
goto out;
/*
@@ -1171,6 +1190,10 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
#endif
kzfree(drbg->seed_buf);
drbg->seed_buf = NULL;
+ if (drbg->jent) {
+ crypto_free_rng(drbg->jent);
+ drbg->jent = NULL;
+ }
}
/*
@@ -1246,14 +1269,29 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
ret = -EFAULT;
goto err;
}
- /* ensure we have sufficient buffer space for initial seed */
+ /*
+* Ensure we have sufficient buffer space for initial seed which
+* consists of the seed from get_random_bytes and the Jitter RNG.
+*/
drbg->seed_buf_len = ((drbg->seed_buf_len + 1) / 2) * 3;
- drbg->seed_buf = kzalloc(drbg->seed_buf_len, GFP_KERNEL);
+ drbg->seed_buf = kzalloc(drbg->seed_buf_len * 2, GFP_KERNEL);
if (!drbg->seed_buf)
goto err;
INIT_WORK(&drbg->seed_work, drbg_async_seed);
+ drbg->jent = crypto_alloc_rng("jitterentropy_rng", 0, 0);
+ if(IS_ERR(drbg->jent))
+ {
+ pr_info("DRBG: cou
[PATCH v7 0/5] Seeding DRBG with more entropy
Hi, as of now, the DRBG is only seeded from get_random_bytes. In various circumstances, the nonblocking_pool behind get_random_bytes may not be fully seeded from hardware events at the time the DRBG requires to be seeded. Based on the discussion in [1], the DRBG seeding is updated such that it does not completely rely on get_random_bytes any more. The seeding approach can be characterized as follows: 1. pull buffer of size entropy + nonce from get_random_bytes 2. pull another buffer of size entropy + nonce from my Jitter RNG 3. concatenate both buffers 4. seed the DRBG with the concatenated buffer 5. trigger the async invocation of the blocking API for accessing the nonblocking pool with a buffer of size entropy 6. return the DRBG instance to the caller without waiting for the completion of step 5 7. at some point in time, the blocking API returns with a full buffer which is then used to re-seed the DRBG This way, we will get entropy during the first initialization without blocking. The patch set adds a blocking API to access the nonblocking pool to wait until the nonblocking pool is initialized. Note: the DRBG and Jitter RNG patches are against the current cryptodev-2.6 tree. The new Jitter RNG is an RNG that has large set of tests and was presented on LKML some time back. After speaking with mathematicians at NIST, that Jitter RNG approach would be acceptable from their side as a noise source. Note, I personally think that the Jitter RNG has sufficient entropy in almost all circumstances (see the massive testing I conducted on all more widely used CPUs as shown in [2]). Changes v7: * patch 01: Catch ERESTARTSYS error for wait_event_interruptible * patch 03: move the cancel invocation to drbg_uninstantiate to ensure that the ->fini function pointer is not yet invoked before the cancel is completed. As the cancel operation may potentially invoke crypto operations, the cipher state must be available. * patch 04: deallocate Jitter RNG after nonblocking_pool is fully initialized. The change implies that regardless of the state of the nonblocking_pool, the Jitter RNG is used for the initial seeding in any case and only dropped for later reseeding operations. Changes v6: * patch 01: simplify patch by just adding a blocking API call to random.c as suggested by Herbert Xu. * patch 03: move the async operation into this patch: the DRBG is in control of the async work. Changes v5: * drop patch 01 and therefore drop the creation of a kernel pool * change patch 02 to use the nonblocking pool and block until the nonblocking pool is initialized or until the cancel operation is triggered. Changes v4: * Patch 02: Change get_blocking_random_bytes_cb to allow callers to call it multiple times without re-initializing the work data structure. Furthermore, only change the pointers to the output buffer and callback if work is not pending to avoid race conditions. * Patch 04: No canceling of seeding during drbg_seed as the invocation of get_blocking_random_bytes_cb can now be done repeatedly without re-initializing the work data structure. Changes v3: * Patch 01: Correct calculation of entropy count as pointed out by Herbert Xu * Patch 06: Correct a trivial coding issue in jent_entropy_init for checking JENT_EMINVARVAR reported by cppcheck Changes v2: * Use Dual BSD/GPL license in MODULE_LICENSE as suggested by Paul Bolle * Patch 05, drbg_dealloc_state: only deallocate Jitter RNG if one was instantiated in the first place. There are two main reasons why the Jitter RNG may not be allocated: either it is not available as kernel module/in vmlinuz or during init time of the Jitter RNG, the performed testing shows that the underlying hardware is not suitable for the Jitter RNG (e.g. has a too coarse timer). [1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg13891.html [2] http://www.chronox.de/jent.html crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/drbg.c | 143 ++-- crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + drivers/char/random.c | 18 + include/crypto/drbg.h | 5 + include/linux/random.h | 1 + 8 files changed, 1065 insertions(+), 27 deletions(-) create mode 100644 crypto/jitterentropy.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 5/5] crypto: add jitterentropy RNG
The CPU Jitter RNG provides a source of good entropy by collecting CPU executing time jitter. The entropy in the CPU execution time jitter is magnified by the CPU Jitter Random Number Generator. The CPU Jitter Random Number Generator uses the CPU execution timing jitter to generate a bit stream which complies with different statistical measurements that determine the bit stream is random. The CPU Jitter Random Number Generator delivers entropy which follows information theoretical requirements. Based on these studies and the implementation, the caller can assume that one bit of data extracted from the CPU Jitter Random Number Generator holds one bit of entropy. The CPU Jitter Random Number Generator provides a decentralized source of entropy, i.e. every caller can operate on a private state of the entropy pool. The RNG does not have any dependencies on any other service in the kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + 4 files changed, 925 insertions(+) create mode 100644 crypto/jitterentropy.c diff --git a/crypto/Kconfig b/crypto/Kconfig index eba55b4..717f2d7 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1478,9 +1478,19 @@ config CRYPTO_DRBG tristate default CRYPTO_DRBG_MENU if (CRYPTO_DRBG_HMAC || CRYPTO_DRBG_HASH || CRYPTO_DRBG_CTR) select CRYPTO_RNG + select CRYPTO_JITTERENTROPY endif # if CRYPTO_DRBG_MENU +config CRYPTO_JITTERENTROPY + tristate "Jitterentropy Non-Deterministic Random Number Generator" + help + The Jitterentropy RNG is a noise that is intended + to provide seed to another RNG. The RNG does not + perform any cryptographic whitening of the generated + random numbers. This Jitterentropy RNG registers with + the kernel crypto API and can be used by any caller. + config CRYPTO_USER_API tristate diff --git a/crypto/Makefile b/crypto/Makefile index 97b7d3a..2f450ef 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -94,6 +94,8 @@ obj-$(CONFIG_CRYPTO_RNG2) += rng.o obj-$(CONFIG_CRYPTO_RNG2) += krng.o obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o obj-$(CONFIG_CRYPTO_DRBG) += drbg.o +CFLAGS_jitterentropy.o = -O0 +obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c new file mode 100644 index 000..1ebe58a --- /dev/null +++ b/crypto/jitterentropy.c @@ -0,0 +1,909 @@ +/* + * Non-physical true random number generator based on timing jitter. + * + * Copyright Stephan Mueller , 2014 + * + * Design + * == + * + * See http://www.chronox.de/jent.html + * + * License + * === + * + * 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 GPL2 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 O
[PATCH v7 3/5] crypto: drbg - add async seeding operation
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the actual seeding of the DRBG.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 24
include/crypto/drbg.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 36dfece..aca8684 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1056,6 +1056,23 @@ static inline int __drbg_seed(struct drbg_state *drbg,
struct list_head *seed,
return ret;
}
+static void drbg_async_seed(struct work_struct *work)
+{
+ struct drbg_string data;
+ LIST_HEAD(seedlist);
+ struct drbg_state *drbg = container_of(work, struct drbg_state,
+ seed_work);
+
+ get_blocking_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+
+ drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
+ list_add_tail(&data.list, &seedlist);
+ mutex_lock(&drbg->drbg_mutex);
+ __drbg_seed(drbg, &seedlist, true);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ mutex_unlock(&drbg->drbg_mutex);
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1125,6 +1142,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
if (!reseed)
drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
+ /* Invoke asynchronous seeding unless DRBG is in test mode. */
+ if (!list_empty(&drbg->test_data.list) && !reseed)
+ schedule_work(&drbg->seed_work);
+
out:
return ret;
}
@@ -1231,6 +1252,8 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->seed_buf)
goto err;
+ INIT_WORK(&drbg->seed_work, drbg_async_seed);
+
return 0;
err:
@@ -1487,6 +1510,7 @@ unlock:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
+ cancel_work_sync(&drbg->seed_work);
if (drbg->d_ops)
drbg->d_ops->crypto_fini(drbg);
drbg_dealloc_state(drbg);
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index b052698..46994b2 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
/*
* Concatenation Helper and string operation helper
@@ -119,6 +120,7 @@ struct drbg_state {
bool fips_primed; /* Continuous test primed? */
unsigned char *prev;/* FIPS 140-2 continuous test value */
#endif
+ struct work_struct seed_work; /* asynchronous seeding support */
u8 *seed_buf; /* buffer holding the seed */
size_t seed_buf_len;
const struct drbg_state_ops *d_ops;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] random: add random_initialized command line param
Am Mittwoch, 20. Mai 2015, 11:06:42 schrieb Theodore Ts'o: Hi Theodore, As a side note to this discussion, may I ask why entropy_total is used for checking against the threshold value and not entropy_count? The reason for my question is the following: until a DRNG (in the worst case, nonblocking_pool is a DRNG) is fully seeded, partial seeds may be "eaten" up by the caller. For the discussion, let us assume the worst case that there is coming in one bit of entropy at a time. In between the addition of each bit of entropy, an attacker can access the DRNG (i.e. the SHA1 output of the nonblocking_pool). When only one bit of entropy is added to the nonblocking_pool, the attack complexity would be 1 bit. When an attacker would access the nonblocking_pool after each received bit, in the worst case, the attack complexity is not 2**128 but rather 256 (i.e. 1 bit for each individual attack between the addition of one new bit of entropy). So, the total attack complexity is the sum of the individual attack complexities (i.e. the complexity added after the previous attack is performed). When using the entropy_count variable which is affected by account() (i.e. it is decreased when a reader obtains data), the threshold is only reached when truly 128 unobserved bits are collected. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] random: add random_initialized command line param
Am Dienstag, 19. Mai 2015, 18:40:20 schrieb Sandy Harris: Hi Sandy, > >When we do do it, I see no reason to support anything other than 128 >and 256, and I am not sure about retaining 128. Nor do I see any >reason this should be a command-line option rather than just a >compile-time constant. I would hazard to guess that a compile time option is a bit difficult for distributions which typically only want one kernel for all their user base. As that user base is typically large, they would potentially be unable to please everybody with a compile time option. But I see that such a change may not be warranted at this point. Though, I see that discussion may rise again in the future when such new requirements for 256 bit keys (not only AES, thanks Sandy for mentioning :-) ) are commonly raised. So, let us disregard the patch until hard requirements are coming up. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Mittwoch, 20. Mai 2015, 06:55:33 schrieb Herbert Xu: Hi Herbert, > >You still need to handle the case where wait_event_interruptible >returns an error. Otherwise this looks fine. Thank you. I would suggest to add a while loop around the call that sets up the wait if it terminated with ERESTARTSYS. This way we can maintain a void function that is almost identical to the get_random_bytes function. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Dienstag, 19. Mai 2015, 22:30:22 schrieb Herbert Xu:
Hi Herbert,
>On Tue, May 19, 2015 at 04:27:54PM +0200, Stephan Mueller wrote:
>> The current modification with patch 1 to random.c is the smallest change to
>> date. Is that then appropriate?
>>
>> Herbert, based on your comment now, would the currently discussed patch
>> with
>> waiting in the work queue in patch 3 appropriate? Or what would you like to
>> see changed?
>
>Sorry but I have lost track as to which patch is which. Please post
>the changes to random.c and we can all take a look.
It would be the patch from the start of the thread as follows.
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked until
the nonblocking_pool is initialized.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
drivers/char/random.c | 14 ++
include/linux/random.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..6f71354 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1245,6 +1245,20 @@ void get_random_bytes(void *buf, int nbytes)
EXPORT_SYMBOL(get_random_bytes);
/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+void get_blocking_random_bytes(void *buf, int nbytes)
+{
+ if (unlikely(nonblocking_pool.initialized == 0))
+ wait_event_interruptible(urandom_init_wait,
+nonblocking_pool.initialized);
+ extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
+}
+EXPORT_SYMBOL(get_blocking_random_bytes);
+
+
+/*
* This function will use the architecture-specific hardware random
* number generator if it is available. The arch-specific hw RNG will
* almost certainly be faster than what we can do in software, but it
diff --git a/include/linux/random.h b/include/linux/random.h
index b05856e..0926d78 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -14,6 +14,7 @@ extern void add_input_randomness(unsigned int type, unsigned
int code,
extern void add_interrupt_randomness(int irq, int irq_flags);
extern void get_random_bytes(void *buf, int nbytes);
+extern void get_blocking_random_bytes(void *buf, int nbytes);
extern void get_random_bytes_arch(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
extern int random_int_secret_init(void);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Dienstag, 19. Mai 2015, 22:18:05 schrieb Herbert Xu: Hi Herbert, >On Tue, May 19, 2015 at 09:50:28AM -0400, Theodore Ts'o wrote: >> Finally, this is only going to block *once*, when the system is >> initially botting up. Why is it so important that we get the >> asynchronous nature of this right, and why can't we solve it simply by >> just simply doing the work in a workqueue, with a completion barrier >> getting triggered once /dev/random initializes itself, and just simply >> blocking the module unload until /dev/random is initialized? > >I guess I'm still thinking of the old work queue code before >Tejun's cmwq work. Yes blocking in a work queue should be fine >as there is usually just one DRBG instance. The current modification with patch 1 to random.c is the smallest change to date. Is that then appropriate? Herbert, based on your comment now, would the currently discussed patch with waiting in the work queue in patch 3 appropriate? Or what would you like to see changed? Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Dienstag, 19. Mai 2015, 15:51:55 schrieb Herbert Xu: Hi Herbert, >You're right. The cancel function is indeed simpler. I can >certainly live with that. Thank you. I will test my patch a bit more and then release it with the discussed changes. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Dienstag, 19. Mai 2015, 15:22:27 schrieb Herbert Xu:
Hi Herbert,
> On Tue, May 19, 2015 at 07:58:25AM +0200, Stephan Mueller wrote:
> > Herbert, do you have any ideas?
>
> On the /dev/random side,
>
> 1) Add a struct module argument in addition to func/data.
> 2) Grab module ref count when func/data is registered.
> 3) Drop module ref count after func returns.
>
> On the drbg side,
>
> 1) Allocate data pointer before func/data registration, it should
> contain a flag indicating whether drbg is still alive.
> 2) In cra_exit, zap the flag in allocated data.
> 3) In func immediately return if flag indicates drbg is dead.
> 4) Free allocated data pointer when func is done.
>
> Obviously you need to add some locking so that func doesn't race
> against cra_exit or any other drbg paths that it intersects.
Thank you for the hints. I will follow your guidance.
Just for my edification: why is this (rather complex sounding) approach
preferred over a simple cancel API? Other async APIs (e.g. the AIO syscalls
with io_cancel) have such cancel operations.
Such cancel function would be as simple as:
void get_blocking_random_bytes_cancel(void *private)
{
struct random_work *rw, *tmp;
mutex_lock(&random_wait_list_mutex);
list_for_each_entry_safe(rw, tmp, &random_wait_list, list) {
if (private == rw->rw_private) {
list_del(&rw->list);
kfree(rw);
break;
}
}
mutex_unlock(&random_wait_list_mutex);
}
--
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Montag, 18. Mai 2015, 11:02:34 schrieb Theodore Ts'o: Hi Theodore, Herbert, > > The simplest thing to do is to put a refcount on inside the DRBG > handle structure. The caller instantiates the DRBG handle, and > invokes the the DRBG. The DRBG, since it is kicking off an > asynchronous operation, increments the refcount. That is a good idea. After experimenting with the refcount, I see that kernel crypto API release function of crypto_destroy_tfm unconditionally destroys the crypto handle by freeing it. So, if a caller releases the DRBG handle, the DRBG code cannot prevent the destruction of its context with a refcount. Herbert, do you have any ideas? -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] random: add random_initialized command line param
Am Montag, 18. Mai 2015, 14:42:09 schrieb Theodore Ts'o: Hi Theodore, >On Mon, May 18, 2015 at 06:25:25PM +0200, Stephan Mueller wrote: >> Make the threshold at which the output entropy pools are considered to >> be initialized configurable via a kernel command line option. The >> current integer value of 128 bits is a good default value. However, some >> user groups may want to use different values. For example, the SOGIS >> group now requires 125 bits at least (BSI, the participant at that group >> used to require 100 bits). NIST moved from 80 bits to 112 bits starting >> with 2014. >> >> It is therefore to be expected that in the future, this threshold may >> increase for different user groups. >> >> CC: Ted Tso >> Signed-off-by: Stephan Mueller > >How much does 125 vs 112 vs 128 bits really matter? Is the cost of >waiting the extra 16 bits (the difference between 112 and 128 bits) >really that high? I'm not entirely convincd that adding Yet Another >Tuning parameter is really worth it. If we stick with 128 bits, we >will satisfy SOGIS, BSI, NIST, etc., and I would find it difficult to >believe that someone would want 132, 147, etc., bits. I hear more and more discussions about recommendations to use AES 256 and not AES 128. These kind of recommendations will eventually also affect the entropy requirements for noise sources. This is my motivation for the patch: allowing different user groups to set the minimum bar for the nonblocking pool to *higher* levels (the examples for 80 to 112 bits or 100 to 125 bits shall just show that there are active revisions of entropy requirements). Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] random: add random_initialized command line param
Make the threshold at which the output entropy pools are considered to
be initialized configurable via a kernel command line option. The
current integer value of 128 bits is a good default value. However, some
user groups may want to use different values. For example, the SOGIS
group now requires 125 bits at least (BSI, the participant at that group
used to require 100 bits). NIST moved from 80 bits to 112 bits starting
with 2014.
It is therefore to be expected that in the future, this threshold may
increase for different user groups.
CC: Ted Tso
Signed-off-by: Stephan Mueller
---
Documentation/kernel-parameters.txt | 7 +++
drivers/char/random.c | 26 +-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 61ab162..bc6c6f1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2965,6 +2965,13 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
ramdisk_size= [RAM] Sizes of RAM disks in kilobytes
See Documentation/blockdev/ramdisk.txt.
+ random_initialized= [KNL] Set the threshold in bits at which the
+ Linux random number generator considers an output
+ entropy pool initialized.
+ Format: (must be >= 112 and <= size of output
+ entropy pool in bits)
+ Default: 128
+
rcu_nocbs= [KNL]
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
the specified list of CPUs to be no-callback CPUs.
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..cfe4d9b 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -317,6 +317,12 @@ static int random_write_wakeup_bits = 28 *
OUTPUT_POOL_WORDS;
static int random_min_urandom_seed = 60;
/*
+ * Threshold of entropy at which an entropy pool is considered to be
+ * initialized.
+ */
+static int random_initialized_threshold = 128;
+
+/*
* Originally, we used a primitive polynomial of degree .poolwords
* over GF(2). The taps for various sizes are defined below. They
* were chosen to be evenly spaced except for the last tap, which is 1
@@ -655,7 +661,8 @@ retry:
goto retry;
r->entropy_total += nbits;
- if (!r->initialized && r->entropy_total > 128) {
+ if (!r->initialized &&
+ r->entropy_total > random_initialized_threshold) {
r->initialized = 1;
r->entropy_total = 0;
if (r == &nonblocking_pool) {
@@ -938,6 +945,23 @@ void add_disk_randomness(struct gendisk *disk)
EXPORT_SYMBOL_GPL(add_disk_randomness);
#endif
+/* Process kernel command-line parameter at boot time. */
+static __init int random_initalized_cmdline(char *str)
+{
+ unsigned long thresh = simple_strtoul(str, NULL, 10);
+
+ if (thresh < 112)
+ thresh = 112;
+ if (thresh > OUTPUT_POOL_WORDS * 32)
+ thresh = OUTPUT_POOL_WORDS * 32;
+ random_initialized_threshold = thresh;
+ pr_notice("random: entropy pool initialization threshold set to %d
bits\n",
+ random_initialized_threshold);
+ return 1;
+}
+
+__setup("random_initialized=", random_initalized_cmdline);
+
/*
*
* Entropy extraction routines
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Montag, 18. Mai 2015, 15:07:10 schrieb Stephan Mueller: Hi Herbert, >> >>You can simplify this further and get rid of buf/nbytes. All >>we need to know is whether the pool is ready. Everything else >>can come from private. > >So, the async function is now just a notification of the caller. Sounds good >with me. > I am just running into an interesting problem with a missing cancel operation: a caller instantiates a DRBG handle and invokes the seeding operation. The nonblocking_pool is not initialized. Therefore, the callback is put onto the list for being processed later. Now, the caller releases the DRBG handle *before* the callback is triggered. The callback is triggered with a pointer that is invalid, but the pointer is non-NULL. Therefore, I am not sure how to validate the pointer in the callback function. I would think that there is no other way than to add a cancel API call that allows removing a list entry from the wait list. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Montag, 18. Mai 2015, 17:21:31 schrieb Herbert Xu: Hi Herbert, >> +/* >> + * Equivalent function to get_random_bytes with the difference that this >> + * function blocks the request until the nonblocking_pool is initialized. >> + */ >> +int get_blocking_random_bytes_cb(void *buf, int nbytes, void *private, >> + void (*cb)(void *buf, int buflen, >> +void *private)) > >You can simplify this further and get rid of buf/nbytes. All >we need to know is whether the pool is ready. Everything else >can come from private. > So, the async function is now just a notification of the caller. Sounds good with me. >> +struct random_work *rw = NULL; >> +int ret = 0; > >I think this function should return 0 if the pool is ready now, >-EINPROGRESS if it's not (indicating that the callback will be >called when it is ready) and otherwise an error. Ok, will come in the next patch. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/5] random: Blocking API for accessing nonblocking_pool
Am Freitag, 15. Mai 2015, 14:46:26 schrieb Herbert Xu:
Hi Herbert,
> On Wed, May 13, 2015 at 09:54:41PM +0200, Stephan Mueller wrote:
> > /*
> >
> > + * Equivalent function to get_random_bytes with the difference that this
> > + * function blocks the request until the nonblocking_pool is initialized.
> > + */
> > +void get_blocking_random_bytes(void *buf, int nbytes)
> > +{
> > + if (unlikely(nonblocking_pool.initialized == 0))
> > + wait_event_interruptible(urandom_init_wait,
> > +nonblocking_pool.initialized);
> > + extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
>
> So what if the wait was interrupted? You are going to extract
> entropy from an empty pool.
>
> Anyway, you still haven't addressed my primary concern with this
> model which is the potential for dead-lock. Sleeping for an open
> period of time like this in a work queue is bad form. It may also
> lead to dead-locks if whatever you're waiting for happened to use
> the same work thread.
>
> That's why I think you should simply provide a function and data
> pointer which random.c can then stash onto a list to call when
> the pool is ready.
Thanks for the hint to the list. Before handing in another formal patch, may i
ask for checking the following approach? I would think that this one should
cover your concerns.
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..9bc2a57 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -409,6 +409,19 @@ static DECLARE_WAIT_QUEUE_HEAD(random_write_wait);
static DECLARE_WAIT_QUEUE_HEAD(urandom_init_wait);
static struct fasync_struct *fasync;
+static LIST_HEAD(random_wait_list);
+static DEFINE_MUTEX(random_wait_list_mutex);
+struct random_work {
+ struct list_headlist;
+ struct work_struct rw_work;
+ void*rw_buf;
+ int rw_len;
+ void*rw_private;
+ void(*rw_cb)(void *buf, int buflen,
+void *private);
+};
+static void process_random_waiters(void);
+
/**
*
* OS independent entropy store. Here are the functions which handle
@@ -660,6 +673,7 @@ retry:
r->entropy_total = 0;
if (r == &nonblocking_pool) {
prandom_reseed_late();
+ process_random_waiters();
wake_up_interruptible(&urandom_init_wait);
pr_notice("random: %s pool is initialized\n", r->name);
}
@@ -1778,3 +1792,64 @@ void add_hwgenerator_randomness(const char *buffer,
size_t count,
credit_entropy_bits(poolp, entropy);
}
EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
+
+static void process_random_waiters(void)
+{
+ struct random_work *rw = NULL;
+
+ mutex_lock(&random_wait_list_mutex);
+ while (!list_empty(&random_wait_list)) {
+ rw = list_first_entry(&random_wait_list, struct random_work,
+ list);
+ list_del(&rw->list);
+ schedule_work(&rw->rw_work);
+ }
+ mutex_unlock(&random_wait_list_mutex);
+}
+
+static void get_blocking_random_bytes_work(struct work_struct *work)
+{
+ struct random_work *rw = container_of(work, struct random_work,
+ rw_work);
+
+ get_random_bytes(rw->rw_buf, rw->rw_len);
+ rw->rw_cb(rw->rw_buf, rw->rw_len, rw->rw_private);
+ kfree(rw);
+}
+
+/*
+ * Equivalent function to get_random_bytes with the difference that this
+ * function blocks the request until the nonblocking_pool is initialized.
+ */
+int get_blocking_random_bytes_cb(void *buf, int nbytes, void *private,
+void (*cb)(void *buf, int buflen,
+ void *private))
+{
+ struct random_work *rw = NULL;
+ int ret = 0;
+
+ mutex_lock(&random_wait_list_mutex);
+ list_for_each_entry(rw, &random_wait_list, list)
+ if (buf == rw->rw_buf)
+ goto out;
+
+ rw = kmalloc(sizeof(struct random_work), GFP_KERNEL);
+ if (!rw) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ INIT_WORK(&rw->rw_work, get_blocking_random_bytes_work);
+ rw->rw_buf = buf;
+ rw->rw_len = nbytes;
+ rw->rw_private = private;
+ rw->rw_cb = cb;
+ list_add_tail(&rw->list, &random_wait_list);
+
+out:
+ mutex_unlock(&random_wait_list_mutex);
+ if (nonblocking_pool.initialized)
+ process_random_w
[PATCH v6 2/5] crypto: drbg - prepare for async seeding
In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for the initial seeding operation as well as by the
asynchronous seeding call. The memory must be zeroized every time the
DRBG seeding call succeeds to avoid entropy data lingering in memory.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 81 ++-
include/crypto/drbg.h | 2 ++
2 files changed, 56 insertions(+), 27 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 23d444e..36dfece 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1041,6 +1041,21 @@ static struct drbg_state_ops drbg_hash_ops = {
* Functions common for DRBG implementations
**/
+static inline int __drbg_seed(struct drbg_state *drbg, struct list_head *seed,
+ int reseed)
+{
+ int ret = drbg->d_ops->update(drbg, seed, reseed);
+
+ if (ret)
+ return ret;
+
+ drbg->seeded = true;
+ /* 10.1.1.2 / 10.1.1.3 step 5 */
+ drbg->reseed_ctr = 1;
+
+ return ret;
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1056,8 +1071,6 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
bool reseed)
{
int ret = 0;
- unsigned char *entropy = NULL;
- size_t entropylen = 0;
struct drbg_string data1;
LIST_HEAD(seedlist);
@@ -1073,26 +1086,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
drbg->test_data.len);
pr_devel("DRBG: using test entropy\n");
} else {
- /*
-* Gather entropy equal to the security strength of the DRBG.
-* With a derivation function, a nonce is required in addition
-* to the entropy. A nonce must be at least 1/2 of the security
-* strength of the DRBG in size. Thus, entropy * nonce is 3/2
-* of the strength. The consideration of a nonce is only
-* applicable during initial seeding.
-*/
- entropylen = drbg_sec_strength(drbg->core->flags);
- if (!entropylen)
- return -EFAULT;
- if (!reseed)
- entropylen = ((entropylen + 1) / 2) * 3;
pr_devel("DRBG: (re)seeding with %zu bytes of entropy\n",
-entropylen);
- entropy = kzalloc(entropylen, GFP_KERNEL);
- if (!entropy)
- return -ENOMEM;
- get_random_bytes(entropy, entropylen);
- drbg_string_fill(&data1, entropy, entropylen);
+drbg->seed_buf_len);
+ get_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+ drbg_string_fill(&data1, drbg->seed_buf, drbg->seed_buf_len);
}
list_add_tail(&data1.list, &seedlist);
@@ -,16 +1108,24 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
memset(drbg->C, 0, drbg_statelen(drbg));
}
- ret = drbg->d_ops->update(drbg, &seedlist, reseed);
+ ret = __drbg_seed(drbg, &seedlist, reseed);
+
+ /*
+* Clear the initial entropy buffer as the async call may not overwrite
+* that buffer for quite some time.
+*/
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
if (ret)
goto out;
-
- drbg->seeded = true;
- /* 10.1.1.2 / 10.1.1.3 step 5 */
- drbg->reseed_ctr = 1;
+ /*
+* For all subsequent seeding calls, we only need the seed buffer
+* equal to the security strength of the DRBG. We undo the calculation
+* in drbg_alloc_state.
+*/
+ if (!reseed)
+ drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
out:
- kzfree(entropy);
return ret;
}
@@ -1143,6 +1148,8 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
drbg->prev = NULL;
drbg->fips_primed = false;
#endif
+ kzfree(drbg->seed_buf);
+ drbg->seed_buf = NULL;
}
/*
@@ -1204,6 +1211,26 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->scratchpad)
goto err;
}
+
+ /*
+* Gather entropy equal to the security strength of the DRBG.
+* With a derivation function, a nonce is required in addition
+* to the entropy. A nonce must b
[PATCH v6 5/5] crypto: add jitterentropy RNG
The CPU Jitter RNG provides a source of good entropy by collecting CPU executing time jitter. The entropy in the CPU execution time jitter is magnified by the CPU Jitter Random Number Generator. The CPU Jitter Random Number Generator uses the CPU execution timing jitter to generate a bit stream which complies with different statistical measurements that determine the bit stream is random. The CPU Jitter Random Number Generator delivers entropy which follows information theoretical requirements. Based on these studies and the implementation, the caller can assume that one bit of data extracted from the CPU Jitter Random Number Generator holds one bit of entropy. The CPU Jitter Random Number Generator provides a decentralized source of entropy, i.e. every caller can operate on a private state of the entropy pool. The RNG does not have any dependencies on any other service in the kernel. The RNG only needs a high-resolution time stamp. Further design details, the cryptographic assessment and large array of test results are documented at http://www.chronox.de/jent.html. CC: Andreas Steffen CC: Theodore Ts'o CC: Sandy Harris Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + 4 files changed, 925 insertions(+) create mode 100644 crypto/jitterentropy.c diff --git a/crypto/Kconfig b/crypto/Kconfig index eba55b4..717f2d7 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1478,9 +1478,19 @@ config CRYPTO_DRBG tristate default CRYPTO_DRBG_MENU if (CRYPTO_DRBG_HMAC || CRYPTO_DRBG_HASH || CRYPTO_DRBG_CTR) select CRYPTO_RNG + select CRYPTO_JITTERENTROPY endif # if CRYPTO_DRBG_MENU +config CRYPTO_JITTERENTROPY + tristate "Jitterentropy Non-Deterministic Random Number Generator" + help + The Jitterentropy RNG is a noise that is intended + to provide seed to another RNG. The RNG does not + perform any cryptographic whitening of the generated + random numbers. This Jitterentropy RNG registers with + the kernel crypto API and can be used by any caller. + config CRYPTO_USER_API tristate diff --git a/crypto/Makefile b/crypto/Makefile index 97b7d3a..2f450ef 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -94,6 +94,8 @@ obj-$(CONFIG_CRYPTO_RNG2) += rng.o obj-$(CONFIG_CRYPTO_RNG2) += krng.o obj-$(CONFIG_CRYPTO_ANSI_CPRNG) += ansi_cprng.o obj-$(CONFIG_CRYPTO_DRBG) += drbg.o +CFLAGS_jitterentropy.o = -O0 +obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy.o obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o diff --git a/crypto/jitterentropy.c b/crypto/jitterentropy.c new file mode 100644 index 000..1ebe58a --- /dev/null +++ b/crypto/jitterentropy.c @@ -0,0 +1,909 @@ +/* + * Non-physical true random number generator based on timing jitter. + * + * Copyright Stephan Mueller , 2014 + * + * Design + * == + * + * See http://www.chronox.de/jent.html + * + * License + * === + * + * 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 GPL2 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 O
[PATCH v6 0/5] Seeding DRBG with more entropy
Hi, as of now, the DRBG is only seeded from get_random_bytes. In various circumstances, the nonblocking_pool behind get_random_bytes may not be fully seeded from hardware events at the time the DRBG requires to be seeded. Based on the discussion in [1], the DRBG seeding is updated such that it does not completely rely on get_random_bytes any more. The seeding approach can be characterized as follows: 1. pull buffer of size entropy + nonce from get_random_bytes 2. pull another buffer of size entropy + nonce from my Jitter RNG 3. concatenate both buffers 4. seed the DRBG with the concatenated buffer 5. trigger the async invocation of the blocking API for accessing the nonblocking pool with a buffer of size entropy 6. return the DRBG instance to the caller without waiting for the completion of step 5 7. at some point in time, the blocking API returns with a full buffer which is then used to re-seed the DRBG This way, we will get entropy during the first initialization without blocking. The patch set adds a blocking API to access the nonblocking pool to wait until the nonblocking pool is initialized. Note: the DRBG and Jitter RNG patches are against the current cryptodev-2.6 tree. The new Jitter RNG is an RNG that has large set of tests and was presented on LKML some time back. After speaking with mathematicians at NIST, that Jitter RNG approach would be acceptable from their side as a noise source. Note, I personally think that the Jitter RNG has sufficient entropy in almost all circumstances (see the massive testing I conducted on all more widely used CPUs as shown in [2]). Changes v6: * patch 01: simplify patch by just adding a blocking API call to random.c as suggested by Herbert Xu. * patch 03: move the async operation into this patch: the DRBG is in control of the async work. Changes v5: * drop patch 01 and therefore drop the creation of a kernel pool * change patch 02 to use the nonblocking pool and block until the nonblocking pool is initialized or until the cancel operation is triggered. Changes v4: * Patch 02: Change get_blocking_random_bytes_cb to allow callers to call it multiple times without re-initializing the work data structure. Furthermore, only change the pointers to the output buffer and callback if work is not pending to avoid race conditions. * Patch 04: No canceling of seeding during drbg_seed as the invocation of get_blocking_random_bytes_cb can now be done repeatedly without re-initializing the work data structure. Changes v3: * Patch 01: Correct calculation of entropy count as pointed out by Herbert Xu * Patch 06: Correct a trivial coding issue in jent_entropy_init for checking JENT_EMINVARVAR reported by cppcheck Changes v2: * Use Dual BSD/GPL license in MODULE_LICENSE as suggested by Paul Bolle * Patch 05, drbg_dealloc_state: only deallocate Jitter RNG if one was instantiated in the first place. There are two main reasons why the Jitter RNG may not be allocated: either it is not available as kernel module/in vmlinuz or during init time of the Jitter RNG, the performed testing shows that the underlying hardware is not suitable for the Jitter RNG (e.g. has a too coarse timer). [1] http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg13891.html [2] http://www.chronox.de/jent.html Stephan Mueller (5): random: Blocking API for accessing nonblocking_pool crypto: drbg - prepare for async seeding crypto: drbg - add async seeding operation crypto: drbg - use Jitter RNG to obtain seed crypto: add jitterentropy RNG crypto/Kconfig | 10 + crypto/Makefile| 2 + crypto/drbg.c | 140 ++-- crypto/jitterentropy.c | 909 + crypto/testmgr.c | 4 + drivers/char/random.c | 14 + include/crypto/drbg.h | 5 + include/linux/random.h | 1 + 8 files changed, 1058 insertions(+), 27 deletions(-) create mode 100644 crypto/jitterentropy.c -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/5] crypto: drbg - add async seeding operation
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the actual seeding of the DRBG.
CC: Andreas Steffen
CC: Theodore Ts'o
CC: Sandy Harris
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 25 +
include/crypto/drbg.h | 2 ++
2 files changed, 27 insertions(+)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 36dfece..2b2738e 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1056,6 +1056,24 @@ static inline int __drbg_seed(struct drbg_state *drbg,
struct list_head *seed,
return ret;
}
+static void drbg_async_seed(struct work_struct *work)
+{
+ struct drbg_string data;
+ LIST_HEAD(seedlist);
+ struct drbg_state *drbg = container_of(work, struct drbg_state,
+ seed_work);
+ int ret = 0;
+
+ get_blocking_random_bytes(drbg->seed_buf, drbg->seed_buf_len);
+
+ drbg_string_fill(&data, drbg->seed_buf, drbg->seed_buf_len);
+ list_add_tail(&data.list, &seedlist);
+ mutex_lock(&drbg->drbg_mutex);
+ ret = __drbg_seed(drbg, &seedlist, true);
+ memzero_explicit(drbg->seed_buf, drbg->seed_buf_len);
+ mutex_unlock(&drbg->drbg_mutex);
+}
+
/*
* Seeding or reseeding of the DRBG
*
@@ -1125,6 +1143,10 @@ static int drbg_seed(struct drbg_state *drbg, struct
drbg_string *pers,
if (!reseed)
drbg->seed_buf_len = drbg->seed_buf_len / 3 * 2;
+ /* Invoke asynchronous seeding unless DRBG is in test mode. */
+ if (!list_empty(&drbg->test_data.list))
+ schedule_work(&drbg->seed_work);
+
out:
return ret;
}
@@ -1134,6 +1156,7 @@ static inline void drbg_dealloc_state(struct drbg_state
*drbg)
{
if (!drbg)
return;
+ cancel_work_sync(&drbg->seed_work);
kzfree(drbg->V);
drbg->V = NULL;
kzfree(drbg->C);
@@ -1231,6 +1254,8 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg->seed_buf)
goto err;
+ INIT_WORK(&drbg->seed_work, drbg_async_seed);
+
return 0;
err:
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index b052698..46994b2 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
/*
* Concatenation Helper and string operation helper
@@ -119,6 +120,7 @@ struct drbg_state {
bool fips_primed; /* Continuous test primed? */
unsigned char *prev;/* FIPS 140-2 continuous test value */
#endif
+ struct work_struct seed_work; /* asynchronous seeding support */
u8 *seed_buf; /* buffer holding the seed */
size_t seed_buf_len;
const struct drbg_state_ops *d_ops;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
