[PATCH -next] crypto: ccp - Fix non static symbol warning

[Wei Yongjun]

Fixes the following sparse warning:

drivers/crypto/ccp/ccp-dev.c:62:14: warning:
 symbol 'ccp_increment_unit_ordinal' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/crypto/ccp/ccp-dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 38a98d8..5d36eef 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -59,7 +59,7 @@ static struct ccp_device *ccp_rr;
 
 /* Ever-increasing value to produce unique unit numbers */
 static atomic_t ccp_unit_ordinal;
-unsigned int ccp_increment_unit_ordinal(void)
+static unsigned int ccp_increment_unit_ordinal(void)
 {
return atomic_inc_return(_unit_ordinal);
 }



--
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

FIPS self test failures (kernel panic) in kernel-4.7

[Tapas Sarangi]

Hello,

A few algorithms are failing Œalg self tests' during kernel boot into FIPS
mode (fips=1), causing a kernel panic (see below). I am using vanilla
kernel-4.7 source for these tests.

These messages were from individual boots into FIPS mode, where algorithms
are taken out from ".fips_allowed=1² and compiled.

Following (see below) is a patch to disable tests for some of these
algorithms work and kernel could boot into FIPS mode (fips=1)
successfully. Please Let me know if there is a deeper/lower-level fix to
this.


##
[1.270663] alg: hash: Failed to load transform for cmac(aes): -2
[1.271471] Kernel panic - not syncing: cmac(aes): cmac(aes) alg self
test failed in fips mode!

[1.256148] alg: hash: Failed to load transform for cmac(des3_ede): -2
[1.257005] Kernel panic - not syncing: cmac(des3_ede): cmac(des3_ede)
alg self test failed in fips mode!
[1.257005]

[1.427856] alg: aead: Failed to load transform for
authenc(hmac(sha1),cbc(des3_ede)): -2
[1.429036] Kernel panic - not syncing:
authenc(hmac(sha1),cbc(des3_ede)): authenc(hmac(sha1),cbc(des3_ede)) alg
self test failed in fips mode!
[1.429036]


[1.316830] alg: aead: Failed to load transform for
authenc(hmac(sha224),cbc(des3_ede)): -2
[1.317914] Kernel panic - not syncing:
authenc(hmac(sha224),cbc(des3_ede)): authenc(hmac(sha224),cbc(des3_ede))
alg self test failed in fips mode!
[1.317914]


[1.262950] alg: aead: Failed to load transform for
authenc(hmac(sha256),cbc(des3_ede)): -2
[1.264094] Kernel panic - not syncing:
authenc(hmac(sha256),cbc(des3_ede)): authenc(hmac(sha256),cbc(des3_ede))
alg self test failed in fips mode!
[1.264094]


##



#‹‹PATCH‹‹
--- a/crypto/testmgr.c  2016-08-11 14:06:15.925140405 -0500
+++ b/crypto/testmgr.c  2016-08-11 15:42:13.954317991 -0500
@@ -2079,7 +2079,6 @@
}, {
.alg = "authenc(hmac(sha1),cbc(des3_ede))",
.test = alg_test_aead,
-   .fips_allowed = 1,
.suite = {
.aead = {
.enc = {
@@ -2133,7 +2132,6 @@
}, {
.alg = "authenc(hmac(sha224),cbc(des3_ede))",
.test = alg_test_aead,
-   .fips_allowed = 1,
.suite = {
.aead = {
.enc = {
@@ -2174,7 +2172,6 @@
}, {
.alg = "authenc(hmac(sha256),cbc(des3_ede))",
.test = alg_test_aead,
-   .fips_allowed = 1,
.suite = {
.aead = {
.enc = {
@@ -2209,7 +2206,6 @@
}, {
.alg = "authenc(hmac(sha384),cbc(des3_ede))",
.test = alg_test_aead,
-   .fips_allowed = 1,
.suite = {
.aead = {
.enc = {
@@ -2258,7 +2254,6 @@
}, {
.alg = "authenc(hmac(sha512),cbc(des3_ede))",
.test = alg_test_aead,
-   .fips_allowed = 1,
.suite = {
.aead = {
.enc = {
@@ -2386,7 +2381,6 @@
}, {
.alg = "cbc(des3_ede)",
.test = alg_test_skcipher,
-   .fips_allowed = 1,
.suite = {
.cipher = {
.enc = {
@@ -2462,7 +2456,6 @@
}
}, {
.alg = "cmac(aes)",
-   .fips_allowed = 1,
.test = alg_test_hash,
.suite = {
.hash = {
@@ -2472,7 +2465,6 @@
}
}, {
.alg = "cmac(des3_ede)",
-   .fips_allowed = 1,
.test = alg_test_hash,
.suite = {
.hash = {
@@ -3753,7 +3745,6 @@
}, {
.alg = "xts(aes)",
.test = alg_test_skcipher,
-   .fips_allowed = 1,
.suite = {
.cipher = {
.enc = {





This transmission may contain information that is privileged, confidential, 
and/or exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the information contained herein (including any reliance thereon) is 
strictly prohibited. If you received this transmission in error, please 
immediately contact the sender and destroy the material in its entirety, 
whether in electronic or hard copy format.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/5] /dev/random - a new approach

[Theodore Ts'o]

On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote:
> 
> The following patch set provides a different approach to /dev/random which
> I call Linux Random Number Generator (LRNG) to collect entropy within the 
> Linux
> kernel. The main improvements compared to the legacy /dev/random is to provide
> sufficient entropy during boot time as well as in virtual environments and 
> when
> using SSDs. A secondary design goal is to limit the impact of the entropy
> collection on massive parallel systems and also allow the use accelerated
> cryptographic primitives. Also, all steps of the entropic data processing are
> testable. Finally massive performance improvements are visible at /dev/urandom
> and get_random_bytes.
> 
> The design and implementation is driven by a set of goals described in [1]
> that the LRNG completely implements. Furthermore, [1] includes a
> comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
> AIS20/31.

Given the changes that have landed in Linus's tree for 4.8, how many
of the design goals for your LRNG are still left not yet achieved?

Reading the paper, you are still claiming huge performance
improvements over getrandomm and /dev/urandom.  With the use of the
ChaCha20 (and given that you added a ChaCha20 DRBG as well), it's not
clear this is still an advantage over what we currently have.

As far as whether or not you can gather enough entropy at boot time,
what we're really talking about how how much entropy we want to assume
can be gathered from interrupt timings, since what you do in your code
is not all that different from what the current random driver is
doing.  So it's pretty easy to turn a knob and say, "hey presto, we
can get all of the entropy we need before userspace starts!"  But
justifying this is much harder, and using statistical tests isn't
really sufficient as far as I'm concerned.

Cheers,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: XTS - remove test that will fail in FIPS mode

[Tapas Sarangi]

Hi Stephan,

Any other ideas about this problem ? Since XTS is not amongst the
self-tests as you observed, is it safe to disable .fips_allowed for
xts(aes) in testmgr.c ?

Thanks
-Tapas


On 8/10/16, 5:08 PM, "Tapas Sarangi"  wrote:

>Hi Stephan,
>
>Thanks. Sorry for a late reply to this.
>
>I did test your patch for testmgr.h with the vanilla kernel 4.7 source.
>This doesn¹t solve the xts(aes) self-test failure in FIPS mode. I get the
>exact same error as before.
>
>Thanks
>-Tapas
>
>
>
>
>
>
>
>On 8/10/16, 12:49 AM, "Stephan Mueller"  wrote:
>
>>Hi Tapas, Herbert,
>>
>>Tapas: this patch should fix it. Can you please test?
>>
>>Herbert: The reason why I have to caught this issue in my tests is the
>>following: I compile xts-aes-aesni statically as you can see below. The
>>self test is marked as passed, although there is no XTS test performed.
>>When you boot in FIPS mode, the testmgr prints out all tests. But XTS is
>>not among them. Do you have an idea why that happens?
>>
>>name : xts(aes)
>>driver   : xts-aes-aesni
>>module   : kernel
>>priority : 400
>>refcnt   : 1
>>selftest : passed
>>internal : no
>>type : ablkcipher
>>async: yes
>>blocksize: 16
>>min keysize  : 32
>>max keysize  : 64
>>ivsize   : 16
>>geniv: 
>>
>>---8<---
>>
>>In FIPS mode, setting XTS keys where the AES key is identical to the
>>tweak key is forbidden. Thus, the self test with such property will fail
>>in FIPS mode.
>>
>>As we have other tests available for XTS, this patch simply removes the
>>offending test vectors.
>>
>>Reported-by: Tapas Sarangi 
>>Signed-off-by: Stephan Mueller 
>>---
>> crypto/testmgr.h | 36 
>> 1 file changed, 36 deletions(-)
>>
>>diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>>index acb6bbf..e4b58f5 100644
>>--- a/crypto/testmgr.h
>>+++ b/crypto/testmgr.h
>>@@ -10179,24 +10179,6 @@ static struct cipher_testvec
>>tf_lrw_dec_tv_template[] = {
>> static struct cipher_testvec tf_xts_enc_tv_template[] = {
>>  /* Generated from AES-XTS test vectors */
>> {
>>- .key= "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .klen   = 32,
>>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .input  = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .ilen   = 32,
>>- .result = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>>-   "\x30\x74\xe4\x44\x52\x77\x97\x43"
>>-   "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>>-   "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>>- .rlen   = 32,
>>- }, {
>>  .key= "\x11\x11\x11\x11\x11\x11\x11\x11"
>>"\x11\x11\x11\x11\x11\x11\x11\x11"
>>"\x22\x22\x22\x22\x22\x22\x22\x22"
>>@@ -10522,24 +10504,6 @@ static struct cipher_testvec
>>tf_xts_dec_tv_template[] = {
>>  /* Generated from AES-XTS test vectors */
>>  /* same as enc vectors with input and result reversed */
>>  {
>>- .key= "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .klen   = 32,
>>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .input  = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>>-   "\x30\x74\xe4\x44\x52\x77\x97\x43"
>>-   "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>>-   "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>>- .ilen   = 32,
>>- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00"
>>-   "\x00\x00\x00\x00\x00\x00\x00\x00",
>>- .rlen   = 32,
>>- }, {
>>  .key= "\x11\x11\x11\x11\x11\x11\x11\x11"
>>"\x11\x11\x11\x11\x11\x11\x11\x11"
>>"\x22\x22\x22\x22\x22\x22\x22\x22"
>>--
>>2.7.4
>>
>>
>




This transmission may contain information that is privileged, confidential, 
and/or exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the 

Data type for aio_buf under X32?

[Jeffrey Walton]

Hi Everyone,

My apologies for this question and my confusion.

When interfacing with the kernel crypto through AF_ALG, what is the
type of 'aio_buf' under X32?

I know is X32 uses ILP32 data model, so integers/longs/pointers are
32-bits (cf., http://www.unix.org/version2/whatsnew/lp64_wp.html). I
believe Glibc uses a 'void*' for 'aio_buf' (cf.,
http://man7.org/linux/man-pages/man7/aio.7.html). But I believe the
kernel's 'aio_buf' is a u64 under X32.

I'm asking due a failure under X32 because GCC sign extends the
pointer value when upsizing to 64-bits (cf., GCC manual 4.7 Arrays and
Pointers, 
http://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html).

Thanks in advance.

Jeff
--
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

D'oh! (Re: robot build error)

[Gary R Hook]

Please ignore this patch.


[PATCH] crypto: CCP - build error: label 'e_hwrng' undefined

Gary R Hook Wed, 10 Aug 2016 12:27:28 -0700

Fix goto target for when registration fails

Reported-by: kbuild test robot 
Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/ccp-dev-v5.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/drivers/crypto/ccp/ccp-dev-v5.c
b/drivers/crypto/ccp/ccp-dev-v5.c
index 4086714..114675e 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -835,7 +835,7 @@ static int ccp5_init(struct ccp_device *ccp)
/* Register the DMA engine support */
ret = ccp_dmaengine_register(ccp);
if (ret)
-   goto e_hwrng;
+   goto e_kthread;

return 0;


--
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


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 4/5] crypto: LRNG - enable compile

[Stephan Mueller]

Am Donnerstag, 11. August 2016, 21:50:15 CEST schrieb kbuild test robot:

Hi,

> Hi Stephan,
> 
> [auto build test ERROR on cryptodev/master]
> [also build test ERROR on v4.8-rc1]
> [cannot apply to next-20160811]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]

Thank you for the report. This is due to the missing include of asm/irq_regs.h 
which seem to be included my the tested arches through some other means.

I will add it in an update.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 4/5] crypto: LRNG - enable compile

[kbuild test robot]

Hi Stephan,

[auto build test ERROR on cryptodev/master]
[also build test ERROR on v4.8-rc1]
[cannot apply to next-20160811]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stephan-Mueller/crypto-DRBG-externalize-DRBG-functions-for-LRNG/20160811-203346
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All error/warnings (new ones prefixed by >>):

   crypto/lrng_base.c: In function 'add_interrupt_randomness':
>> crypto/lrng_base.c:583:10: error: implicit declaration of function 
>> 'get_irq_regs'
>> crypto/lrng_base.c:583:26: warning: initialization makes pointer from 
>> integer without a cast [enabled by default]
   cc1: some warnings being treated as errors

vim +/get_irq_regs +583 crypto/lrng_base.c

22708393 Stephan Mueller 2016-08-11  567  }
22708393 Stephan Mueller 2016-08-11  568  
22708393 Stephan Mueller 2016-08-11  569  /**
22708393 Stephan Mueller 2016-08-11  570   * Hot code path - Callback for 
interrupt handler
22708393 Stephan Mueller 2016-08-11  571   */
22708393 Stephan Mueller 2016-08-11  572  void add_interrupt_randomness(int 
irq, int irq_flags)
22708393 Stephan Mueller 2016-08-11  573  {
22708393 Stephan Mueller 2016-08-11  574u32 now_time = 
random_get_entropy();
22708393 Stephan Mueller 2016-08-11  575struct lrng_irq_info *irq_info 
= _pool.irq_info;
22708393 Stephan Mueller 2016-08-11  576u32 irq_num = 
(u32)atomic_add_return(1, _info->num_events);
22708393 Stephan Mueller 2016-08-11  577  
22708393 Stephan Mueller 2016-08-11  578if 
(lrng_pool.irq_info.irq_highres_timer) {
22708393 Stephan Mueller 2016-08-11  579if 
(lrng_irq_stuck(irq_info, now_time))
22708393 Stephan Mueller 2016-08-11  580return;
22708393 Stephan Mueller 2016-08-11  581lrng_pool_mixin((u8 
*)_time, sizeof(now_time), irq_num);
22708393 Stephan Mueller 2016-08-11  582} else {
22708393 Stephan Mueller 2016-08-11 @583struct pt_regs *regs = 
get_irq_regs();
22708393 Stephan Mueller 2016-08-11  584static atomic_t reg_idx 
= ATOMIC_INIT(0);
22708393 Stephan Mueller 2016-08-11  585  
22708393 Stephan Mueller 2016-08-11  586struct {
22708393 Stephan Mueller 2016-08-11  587long jiffies;
22708393 Stephan Mueller 2016-08-11  588int irq;
22708393 Stephan Mueller 2016-08-11  589int irq_flags;
22708393 Stephan Mueller 2016-08-11  590u64 ip;
22708393 Stephan Mueller 2016-08-11  591u32 curr_reg;

:: The code at line 583 was first introduced by commit
:: 227083931f3541c5430b40241419b56057555033 crypto: Linux Random Number 
Generator

:: TO: Stephan Mueller <smuel...@chronox.de>
:: CC: 0day robot <fengguang...@intel.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 2/2] ath9k: disable RNG by default

[Jason Cooper]

On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoq...@codeaurora.org wrote:
> On 2016-08-10 21:24, Jason Cooper wrote:
> >The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> >the appropriate place for it.  It's not a devicetree blob, mac address,
> >or pci config space.  Which are things we feed in once for the heck of
> >it.  This is a *continuous* source or questionable quality.
> >
> >I'm seriously considering putting this and timeriomem-rng into a
> >subdirectory under hw_random/, maybe environ/.  Anything in there gets
> >quality=0 for default, and *doesn't* contribute to /dev/hwrng.
> >
> >Regardless which path we take, I think we should include 'adc' in the
> >name.  I've heard countless times about "Atheros cards come with an rng
> >on board". :-/
> 
> If I understand correctly, you want to bind the ADC source to
> /dev/hwrng, and then change rng-tools to set the entropy to zero in
> the ioctl call ?  There are two major problems with that approach,

Nope.  I want to leverage the hwrng framework to facilitate feeding the
*kernel* entropy pools like all the other hwrngs do currently.  The
difference for *environmental* sources is that when userspace read()s
from /dev/hwrng, they will *not* contribute.

If the environmental sources are the only sources, then no /dev/hwrng
should appear.

> 1) We already tried once before to bind our solution to /dev/hwrng,
> and got so much complaints. The conclusion was that maybe we know that
> the output of /dev/hwrng does not have perfect entropy, but a normal
> user does not know and will misuse it. You mentioned in
> https://www.kernel.org/doc/Documentation/hw_random.txt we have
> 
> "This data is NOT CHECKED by any
>   fitness tests, and could potentially be bogus (if the
>   hardware is faulty or has been tampered with).  Data is only
>   output if the hardware "has-data" flag is set, but nevertheless
>   a security-conscious person would run fitness tests on the
>   data before assuming it is truly random."
> 
> But this is not enough to convince upstream to switch to /dev/hwrng.
> I think the concern of users misusing the solution is a very valid
> concern.

Agreed.

> 2) If we set the entropy to zero in rng-tools, we cannot tolerate the
> load.  Rng-tools is not a timer-based solution. Similar to our
> solution, it is based on
> /proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
> the entropy counter, rng-tools keep writing into the pool, and both
> rng-tools and WiFi chip will be overloaded.

That's why I propose a change to the hwrng framework to permit noise
sources while not wiring them up to feed /dev/hwrng.  timeriomem-rng
should have the same problem ath9k-rng does.

Basically, if it wasn't designed to be an rng, it shouldn't be wired up
to /dev/hwrng.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 4/5] crypto: LRNG - enable compile

[Stephan Mueller]

Add LRNG compilation support.

Signed-off-by: Stephan Mueller 
---
 crypto/Kconfig  | 11 +++
 crypto/Makefile |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 84d7148..71df7fc 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1665,6 +1665,17 @@ config CRYPTO_JITTERENTROPY
  random numbers. This Jitterentropy RNG registers with
  the kernel crypto API and can be used by any caller.
 
+config CRYPTO_LRNG
+   bool "Linux Random Number Generator"
+   select CRYPTO_DRBG_MENU
+   select CRYPTO_CMAC if CRYPTO_DRBG_CTR
+   help
+ The Linux Random Number Generator (LRNG) is the replacement
+ of the legacy /dev/random provided with drivers/char/random.c.
+ It generates entropy from different noise sources and
+ delivers significant entropy during boot. The LRNG only
+ works with the presence of a high-resolution timer.
+
 config CRYPTO_USER_API
tristate
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 99cc64a..12d4249 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -122,6 +122,8 @@ obj-$(CONFIG_CRYPTO_DRBG) += drbg.o
 obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy_rng.o
 CFLAGS_jitterentropy.o = -O0
 jitterentropy_rng-y := jitterentropy.o jitterentropy-kcapi.o
+obj-$(CONFIG_CRYPTO_LRNG) += lrng.o
+lrng-y += lrng_base.o lrng_kcapi.o
 obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
 obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
 obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 0/5] /dev/random - a new approach

[Stephan Mueller]

Hi Herbert, Ted,

The following patch set provides a different approach to /dev/random which
I call Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the legacy /dev/random is to provide
sufficient entropy during boot time as well as in virtual environments and when
using SSDs. A secondary design goal is to limit the impact of the entropy
collection on massive parallel systems and also allow the use accelerated
cryptographic primitives. Also, all steps of the entropic data processing are
testable. Finally massive performance improvements are visible at /dev/urandom
and get_random_bytes.

The design and implementation is driven by a set of goals described in [1]
that the LRNG completely implements. Furthermore, [1] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.

Changes v6:
* port to 4.8-rc1
* add missing memzero_explicit to ChaCha20 DRNG
* use kernel-doc documentation style
* use of min3 in lrng_get_pool to beautify code
* prevent fast noise sources from dominating slow noise sources
  in case of /dev/random
* set read wakeup threshold to 64 bits to comply with legacy /dev/random
* simplify the interrupt to entropy amount conversion code
* move wakeup call of entropy-providers to a code location where /dev/urandom
  will benefit from the wake up as well (i.e. when the primary DRBG entropy
  runs low because of /dev/urandom reseeds, the entropy provider is woken up)
* inject current time into primary DRBG at the time of seeding from noise
  sources (suggested by Sandy Harris)

Changes v5:
* fix treating LRNG_POOL_SIZE_BITS as entropy value in lrng_get_pool
* use CTR DRBG with AES256 as default due to its superior speed -- on X86_64
  executing within a KVM I get read speeds of up to 850 MB/s now. When using a
  fake NUMA system with 4 nodes on 4 CPUs, I still get up to 430 MB/s read speed
  with four parallel reads. Note, this patch applies to the current
  cryptodev-2.6 tree.
* simplify lrng_get_arch
* use DRBG security strengths as defined in SP800-57 section 5.6.1
* add security strength to /proc/sys/kernel/random/lrng_type
* add ChaCha20 DRNG: in case the kernel crypto API is not compiled, the ChaCha20
  DRNG with the SHA-1 C implementations are used to drive the cryptographic part
  of the LRNG.The ChaCha20 RNG is described in [1]. I analyzed it with a user
  space version of it.
* Editorial changes requested by checkpatch.pl

Changes v4:
* port to 4.7-rc1
* Use classical twisted LFSR approach to collect entropic data as requested by
  George Spelvin. The LFSR is based on a primitive and irreducible polynomial
  whose taps are not too close to the location the current byte is mixed in.
  Primitive polynomials for other entropy pool sizes are offered in the code.
* The reading of the entropy pool is performed with a hash. The hash can be
  specified at compile time. The pre-defined hashes are the same as used for
  the DRBG type (e.g. a SHA256 Hash DRBG implies the use of SHA-256, an AES256
  CTR DRBG implies the use of CMAC-AES).
* Addition of the example defines for a CTR DRBG with AES128 which can be
  enabled during compile time.
* Entropy estimate: one bit of entropy per interrupt. In case a system does
  not have a high-resolution timer, apply 1/10th bit of entropy per interrupt.
  The interrupt estimates can be changed arbitrarily at compile time.
* Use kmalloc_node for the per-NUMA node secondary DRBGs.
* Add boot time entropy tests discussed in section 3.4.3 [1].
* Align all buffers that are processed by the kernel crypto API to an 8 byte
  boundary. This boundary covers all currently existing cipher implementations.

Changes v3:
* Convert debug printk to pr_debug as suggested by Joe Perches
* Add missing \n as suggested by Joe Perches
* Do not mix in struck IRQ measurements as requested by Pavel Machek
* Add handling logic for systems without high-res timer as suggested by Pavel
  Machek -- it uses ideas from the add_interrupt_randomness of the legacy
  /dev/random implementation
* add per NUMA node secondary DRBGs as suggested by Andi Kleen -- the
  explanation of how the logic works is given in section 2.1.1 of my
  documentation [1], especially how the initial seeding is performed.

Changes v2:
* Removal of the Jitter RNG fast noise source as requested by Ted
* Addition of processing of add_input_randomness as suggested by Ted
* Update documentation and testing in [1] to cover the updates
* Addition of a SystemTap script to test add_input_randomness
* To clarify the question whether sufficient entropy is present during boot
  I added one more test in 3.3.1 [1] which demonstrates the providing of
  sufficient entropy during initialization. In the worst case of no fast noise
  sources, in the worst case of a virtual machine with only very few hardware
  devices, the testing shows that the secondary DRBG is fully seeded with 256
  bits of entropy before user space injects the random 

[PATCH v6 1/5] crypto: DRBG - externalize DRBG functions for LRNG

[Stephan Mueller]

This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.

Signed-off-by: Stephan Mueller 
---
 crypto/drbg.c | 11 +--
 include/crypto/drbg.h |  7 +++
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/crypto/drbg.c b/crypto/drbg.c
index f752da3..42084c2 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -113,7 +113,7 @@
  * the SHA256 / AES 256 over other ciphers. Thus, the favored
  * DRBGs are the latest entries in this array.
  */
-static const struct drbg_core drbg_cores[] = {
+const struct drbg_core drbg_cores[] = {
 #ifdef CONFIG_CRYPTO_DRBG_CTR
{
.flags = DRBG_CTR | DRBG_STRENGTH128,
@@ -205,7 +205,7 @@ static int drbg_uninstantiate(struct drbg_state *drbg);
  * Return: normalized strength in *bytes* value or 32 as default
  *to counter programming errors
  */
-static inline unsigned short drbg_sec_strength(drbg_flag_t flags)
+unsigned short drbg_sec_strength(drbg_flag_t flags)
 {
switch (flags & DRBG_STRENGTH_MASK) {
case DRBG_STRENGTH128:
@@ -1128,7 +1128,7 @@ static int drbg_seed(struct drbg_state *drbg, struct 
drbg_string *pers,
 }
 
 /* Free all substructures in a DRBG state without the DRBG state structure */
-static inline void drbg_dealloc_state(struct drbg_state *drbg)
+void drbg_dealloc_state(struct drbg_state *drbg)
 {
if (!drbg)
return;
@@ -1147,7 +1147,7 @@ static inline void drbg_dealloc_state(struct drbg_state 
*drbg)
  * Allocate all sub-structures for a DRBG state.
  * The DRBG state structure must already be allocated.
  */
-static inline int drbg_alloc_state(struct drbg_state *drbg)
+int drbg_alloc_state(struct drbg_state *drbg)
 {
int ret = -ENOMEM;
unsigned int sb_size = 0;
@@ -1781,8 +1781,7 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
  *
  * return: flags
  */
-static inline void drbg_convert_tfm_core(const char *cra_driver_name,
-int *coreref, bool *pr)
+void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref, bool *pr)
 {
int i = 0;
size_t start = 0;
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 61580b1..1755d07 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -280,4 +280,11 @@ enum drbg_prefixes {
DRBG_PREFIX3
 };
 
+extern int drbg_alloc_state(struct drbg_state *drbg);
+extern void drbg_dealloc_state(struct drbg_state *drbg);
+extern void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref,
+ bool *pr);
+extern const struct drbg_core drbg_cores[];
+extern unsigned short drbg_sec_strength(drbg_flag_t flags);
+
 #endif /* _DRBG_H */
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/5] crypto: Linux Random Number Generator

[Stephan Mueller]

The LRNG with the following properties:

* noise source: interrupts timing with fast boot time seeding

* lockless LFSR to collect raw entropy

* use of kernel crypto API DRBG

* in case kernel crypto API is not compiled, use standalone
  ChaCha20 based RNG

* used cipher types for hashes and DRBG is selectable at
  compile time

* "atomic" seeding of secondary DRBG to ensure full entropy
  transport

* instantiate one DRBG per NUMA node

Further details including the rationale for the design choices and
properties of the LRNG together with testing is provided at [1].
In addition, the documentation explains the conducted regression
tests to verify that the LRNG is API and ABI compatible with the
legacy /dev/random implementation.

Signed-off-by: Stephan Mueller 
---
 crypto/lrng_base.c  | 1960 +++
 crypto/lrng_kcapi.c |  167 +
 2 files changed, 2127 insertions(+)
 create mode 100644 crypto/lrng_base.c
 create mode 100644 crypto/lrng_kcapi.c

diff --git a/crypto/lrng_base.c b/crypto/lrng_base.c
new file mode 100644
index 000..ab92298
--- /dev/null
+++ b/crypto/lrng_base.c
@@ -0,0 +1,1960 @@
+/*
+ * Linux Random Number Generator (LRNG)
+ *
+ * Documentation and test code: http://www.chronox.de/lrng.html
+ *
+ * Copyright (C) 2016, Stephan Mueller 
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Define a DRBG plus a hash / MAC used to extract data from the entropy pool.
+ * For LRNG_HASH_NAME you can use a hash or a MAC (HMAC or CMAC) of your choice
+ * (Note, you should use the suggested selections below -- using SHA-1 or MD5
+ * is not wise). The idea is that the used cipher primitive can be selected to
+ * be the same as used for the DRBG. I.e. the LRNG only uses one cipher
+ * primitive using the same cipher implementation with the options offered in
+ * the following. This means, if the CTR DRBG is selected and AES-NI is 
present,
+ * both the CTR DRBG and the selected cmac(aes) use AES-NI.
+ *
+ * The security strengths of the DRBGs are taken from SP800-57 section 5.6.1.
+ *
+ * This definition is allowed to be changed.
+ */
+#ifdef CONFIG_CRYPTO_DRBG_CTR
+# define LRNG_HASH_NAME "cmac(aes)"
+# if 0
+#  define LRNG_DRBG_BLOCKLEN_BYTES 16
+#  define LRNG_DRBG_SECURITY_STRENGTH_BYTES 16
+#  define LRNG_DRBG_CORE "drbg_nopr_ctr_aes128"/* CTR DRBG 
AES-128 */
+# else
+#  define LRNG_DRBG_BLOCKLEN_BYTES 16
+#  define LRNG_DRBG_SECURITY_STRENGTH_BYTES 32
+#  define LRNG_DRBG_CORE "drbg_nopr_ctr_aes256"/* CTR DRBG 
AES-256 */
+# endif
+#elif defined CONFIG_CRYPTO_DRBG_HMAC
+# if 0
+#  define LRNG_DRBG_BLOCKLEN_BYTES 32
+#  define LRNG_DRBG_SECURITY_STRENGTH_BYTES 16
+#  define LRNG_DRBG_CORE "drbg_nopr_hmac_sha256"   /* HMAC DRBG SHA-256 */
+#  define LRNG_HASH_NAME "sha256"
+# else
+#  define LRNG_DRBG_BLOCKLEN_BYTES 64
+#  define LRNG_DRBG_SECURITY_STRENGTH_BYTES 32
+#  define LRNG_DRBG_CORE 

[PATCH v6 2/5] random: conditionally compile code depending on LRNG

[Stephan Mueller]

When selecting the LRNG for compilation, disable the legacy /dev/random
implementation.

The LRNG is a drop-in replacement for the legacy /dev/random which
implements the same in-kernel and user space API. Only the hooks of
/dev/random into other parts of the kernel need to be disabled.

Signed-off-by: Stephan Mueller 
---
 drivers/char/random.c  | 8 
 include/linux/genhd.h  | 5 +
 include/linux/random.h | 7 ++-
 3 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 3efb3bf..730a12e 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -270,6 +270,8 @@
 #include 
 #include 
 
+#ifndef CONFIG_CRYPTO_LRNG
+
 #define CREATE_TRACE_POINTS
 #include 
 
@@ -1898,6 +1900,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, 
count,
}
return urandom_read(NULL, buf, count, NULL);
 }
+#endif /* CONFIG_CRYPTO_LRNG */
 
 /
  *
@@ -1905,6 +1908,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, 
count,
  *
  /
 
+#ifndef CONFIG_CRYPTO_LRNG
 #ifdef CONFIG_SYSCTL
 
 #include 
@@ -2042,6 +2046,8 @@ struct ctl_table random_table[] = {
 };
 #endif /* CONFIG_SYSCTL */
 
+#endif /* CONFIG_CRYPTO_LRNG */
+
 static u32 random_int_secret[MD5_MESSAGE_BYTES / 4] cacheline_aligned;
 
 int random_int_secret_init(void)
@@ -2119,6 +2125,7 @@ randomize_range(unsigned long start, unsigned long end, 
unsigned long len)
return PAGE_ALIGN(get_random_int() % range + start);
 }
 
+#ifndef CONFIG_CRYPTO_LRNG
 /* Interface for in-kernel drivers of true hardware RNGs.
  * Those devices may produce endless random bits and will be throttled
  * when our pool is full.
@@ -2143,3 +2150,4 @@ void add_hwgenerator_randomness(const char *buffer, 
size_t count,
credit_entropy_bits(poolp, entropy);
 }
 EXPORT_SYMBOL_GPL(add_hwgenerator_randomness);
+#endif /* CONFIG_CRYPTO_LRNG */
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index 1dbf52f..387770d1 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -437,8 +437,13 @@ extern void disk_flush_events(struct gendisk *disk, 
unsigned int mask);
 extern unsigned int disk_clear_events(struct gendisk *disk, unsigned int mask);
 
 /* drivers/char/random.c */
+#ifdef CONFIG_CRYPTO_LRNG
+#define add_disk_randomness(disk) do {} while (0)
+#define rand_initialize_disk(disk) do {} while (0)
+#else
 extern void add_disk_randomness(struct gendisk *disk);
 extern void rand_initialize_disk(struct gendisk *disk);
+#endif
 
 static inline sector_t get_start_sect(struct block_device *bdev)
 {
diff --git a/include/linux/random.h b/include/linux/random.h
index 3d6e981..fd39c11 100644
--- a/include/linux/random.h
+++ b/include/linux/random.h
@@ -17,10 +17,15 @@ struct random_ready_callback {
struct module *owner;
 };
 
-extern void add_device_randomness(const void *, unsigned int);
 extern void add_input_randomness(unsigned int type, unsigned int code,
 unsigned int value);
 extern void add_interrupt_randomness(int irq, int irq_flags);
+#ifdef CONFIG_CRYPTO_LRNG
+#define add_device_randomness(buf, nbytes) do {} while (0)
+#else  /* CONFIG_CRYPTO_LRNG */
+extern void add_device_randomness(const void *, unsigned int);
+#define lrng_irq_process()
+#endif /* CONFIG_CRYPTO_LRNG */
 
 extern void get_random_bytes(void *buf, int nbytes);
 extern int add_random_ready_callback(struct random_ready_callback *rdy);
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] X.509: Fix double free in x509_cert_parse().

[Artem Savkov]

Patch "crypto: KEYS: convert public key and digsig asym to the akcipher
api" introduced double freeing of cert->pub->key. There is no need to free
it in error_decode label as it is later freed in x509_free_certificate().

Signed-off-by: Artem Savkov 
---
 crypto/asymmetric_keys/x509_cert_parser.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/crypto/asymmetric_keys/x509_cert_parser.c 
b/crypto/asymmetric_keys/x509_cert_parser.c
index 1f1899d..9157071 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -133,7 +133,6 @@ struct x509_certificate *x509_cert_parse(const void *data, 
size_t datalen)
return cert;
 
 error_decode:
-   kfree(cert->pub->key);
kfree(ctx);
 error_no_ctx:
x509_free_certificate(cert);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 5/5] crypto: LRNG - add ChaCha20 support

[Stephan Mueller]

In case the kernel crypto API is not compiled, use ChaCha20 stream
cipher as DRNG. The LRNG ChaCha20 support provides the DRNG
implementation with the generate and update functions.

Th DRNG implements enhanced backward secrecy by re-creating the
entire internal state after generating random numbers.

Signed-off-by: Stephan Mueller 
---
 crypto/Kconfig   |   1 -
 crypto/Makefile  |   7 +-
 crypto/lrng_standalone.c | 220 +++
 3 files changed, 226 insertions(+), 2 deletions(-)
 create mode 100644 crypto/lrng_standalone.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 71df7fc..ee5aff4 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1667,7 +1667,6 @@ config CRYPTO_JITTERENTROPY
 
 config CRYPTO_LRNG
bool "Linux Random Number Generator"
-   select CRYPTO_DRBG_MENU
select CRYPTO_CMAC if CRYPTO_DRBG_CTR
help
  The Linux Random Number Generator (LRNG) is the replacement
diff --git a/crypto/Makefile b/crypto/Makefile
index 12d4249..99fb0e1 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -123,7 +123,12 @@ obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy_rng.o
 CFLAGS_jitterentropy.o = -O0
 jitterentropy_rng-y := jitterentropy.o jitterentropy-kcapi.o
 obj-$(CONFIG_CRYPTO_LRNG) += lrng.o
-lrng-y += lrng_base.o lrng_kcapi.o
+lrng-y += lrng_base.o
+ifeq ($(CONFIG_CRYPTO_DRBG),y)
+lrng-y += lrng_kcapi.o
+else
+lrng-y += lrng_standalone.o
+endif
 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/lrng_standalone.c b/crypto/lrng_standalone.c
new file mode 100644
index 000..7c5d456
--- /dev/null
+++ b/crypto/lrng_standalone.c
@@ -0,0 +1,220 @@
+/*
+ * Backend for the LRNG providing the cryptographic primitives using
+ * standalone cipher implementations.
+ *
+ * Copyright (C) 2016, Stephan Mueller 
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+
+/*** ChaCha20 DRNG ***/
+
+/* State according to RFC 7539 section 2.3 */
+struct chacha20_state {
+   u32 constants[4];
+   union {
+   u32 u[(CHACHA20_KEY_SIZE / sizeof(u32))];
+   u8  b[CHACHA20_KEY_SIZE];
+   } key;
+   u32 counter;
+   u32 nonce[3];
+};
+
+/**
+ * Update of the ChaCha20 state by generating one ChaCha20 block which is
+ * equal to the state of the ChaCha20. The generated block is XORed into
+ * the key part of the state. This shall ensure backtracking resistance as well
+ * as a proper mix of the ChaCha20 state once the key is injected.
+ */
+static void lrng_chacha20_update(struct chacha20_state *chacha20)
+{
+   u32 tmp[(CHACHA20_BLOCK_SIZE / sizeof(u32))];
+   u32 i;
+
+   BUILD_BUG_ON(sizeof(struct chacha20_state) != CHACHA20_BLOCK_SIZE);
+   BUILD_BUG_ON(CHACHA20_BLOCK_SIZE != 2 * CHACHA20_KEY_SIZE);
+
+   chacha20_block(>constants[0], tmp);
+   for (i = 0; i < (CHACHA20_KEY_SIZE / sizeof(uint32_t)); i++)
+