* Re: [PATCH] crypto: caam - replace deprecated EXTRA_CFLAGS
From: Herbert Xu @ 2016-06-20 11:34 UTC (permalink / raw)
To: Tudor Ambarus; +Cc: linux-crypto, horia.geanta
In-Reply-To: <1466083975-27054-1-git-send-email-tudor-dan.ambarus@nxp.com>
On Thu, Jun 16, 2016 at 04:32:55PM +0300, Tudor Ambarus wrote:
> EXTRA_CFLAGS is still supported but its usage is deprecated.
>
> Signed-off-by: Tudor Ambarus <tudor-dan.ambarus@nxp.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 01/28] crypto: omap-aes: Fix registration of algorithms
From: Tero Kristo @ 2016-06-20 12:11 UTC (permalink / raw)
To: Herbert Xu
Cc: tony, lokeshvutla, linux-crypto, linux-omap, davem,
linux-arm-kernel
In-Reply-To: <20160607104821.GA520@gondor.apana.org.au>
On 07/06/16 13:48, Herbert Xu wrote:
> On Wed, Jun 01, 2016 at 11:56:02AM +0300, Tero Kristo wrote:
>> From: Lokesh Vutla <lokeshvutla@ti.com>
>>
>> Algorithms can be registered only once. So skip registration of
>> algorithms if already registered (i.e. in case we have two AES cores
>> in the system.)
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>
> Patch applied. Thanks.
>
Thanks,
Did you check the rest of the series? I only got feedback for this and
patch #2 on the series, shall I repost the remainder of the series as a
whole or...?
-Tero
^ permalink raw reply
* Re: [PATCH] crypto: fix semicolon.cocci warnings
From: Herbert Xu @ 2016-06-20 11:33 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, linux-crypto, Stephan Mueller
In-Reply-To: <20160615111325.GA68889@ivytown2>
On Wed, Jun 15, 2016 at 07:13:25PM +0800, kbuild test robot wrote:
> crypto/drbg.c:1637:39-40: Unneeded semicolon
>
>
> Remove unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Stephan Mueller <smueller@chronox.de>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [patch] crypto: drbg - fix an error code in drbg_init_sym_kernel()
From: Herbert Xu @ 2016-06-20 11:35 UTC (permalink / raw)
To: Dan Carpenter
Cc: Stephan Mueller, David S. Miller, linux-crypto, linux-kernel,
kernel-janitors
In-Reply-To: <20160617091618.GC25609@mwanda>
On Fri, Jun 17, 2016 at 12:16:19PM +0300, Dan Carpenter wrote:
> We accidentally return PTR_ERR(NULL) which is success but we should
> return -ENOMEM.
>
> Fixes: 355912852115 ('crypto: drbg - use CTR AES instead of ECB AES')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: [PATCH v9 2/3] crypto: kpp - Add DH software implementation
From: Benedetto, Salvatore @ 2016-06-20 11:44 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org, Benedetto, Salvatore
In-Reply-To: <20160620111310.GA10601@gondor.apana.org.au>
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Monday, June 20, 2016 12:13 PM
> To: Benedetto, Salvatore <salvatore.benedetto@intel.com>
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v9 2/3] crypto: kpp - Add DH software implementation
>
> On Fri, Jun 17, 2016 at 03:37:44PM +0100, Salvatore Benedetto wrote:
> >
> > +int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh
> > +*params) {
> > + struct kpp_secret *secret = (struct kpp_secret *)buf;
>
> You can't do that. The memory under buf may not be aligned so you need to
> copy it.
OK, I'll fix that and send a new version unless you have other comments.
Thanks for reviewing.
Salvatore
^ permalink raw reply
* RE: [PATCH v9 2/3] crypto: kpp - Add DH software implementation
From: Benedetto, Salvatore @ 2016-06-20 11:43 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org, Benedetto, Salvatore
In-Reply-To: <20160620111524.GB10601@gondor.apana.org.au>
> -----Original Message-----
> From: Herbert Xu [mailto:herbert@gondor.apana.org.au]
> Sent: Monday, June 20, 2016 12:15 PM
> To: Benedetto, Salvatore <salvatore.benedetto@intel.com>
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [PATCH v9 2/3] crypto: kpp - Add DH software implementation
>
> On Fri, Jun 17, 2016 at 03:37:44PM +0100, Salvatore Benedetto wrote:
> > * Implement MPI based Diffie-Hellman under kpp API
> >
> > +struct dh {
> > + void *key;
> > + void *p;
> > + void *g;
> > + unsigned int key_size;
> > + unsigned int p_size;
> > + unsigned int g_size;
> > +};
> > +
> > +int crypto_dh_key_len(const struct dh *params); int
> > +crypto_dh_encode_key(char *buf, unsigned int len, const struct dh
> > +*params); int crypto_dh_decode_key(const char *buf, unsigned int len,
> > +struct dh **params);
>
> While you're at it, it would be nice if you could make the encoded format
> little-endian, that way we can make test vectors for all kpp algorithms use
> the same format.
>
The input format is the same for DH and ECDH.
Only the software implementation of ECC requires little-endian format.
Regards,
Salvatore
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/2] Add SHA-3 algorithm and test vectors.
From: Herbert Xu @ 2016-06-20 11:35 UTC (permalink / raw)
To: Raveendra Padasalagi
Cc: David S. Miller, linux-crypto, linux-kernel, Jon Mason,
Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list
In-Reply-To: <1466139636-19779-1-git-send-email-raveendra.padasalagi@broadcom.com>
On Fri, Jun 17, 2016 at 10:30:34AM +0530, Raveendra Padasalagi wrote:
> This patchset adds the implementation of SHA-3 algorithm
> in software and it's based on original implementation
> pushed in patch https://lwn.net/Articles/518415/ with
> additional changes to match the padding rules specified
> in SHA-3 specification.
>
> This patchset also includes changes in tcrypt module to
> add support for SHA-3 algorithms test and related test
> vectors for basic testing.
>
> Broadcom Secure Processing Unit-2(SPU-2) engine supports
> offloading of SHA-3 operations in hardware, in order to
> add SHA-3 support in SPU-2 driver we needed to have the
> software implementation and test framework in place.
>
> The patchset is based on v4.7-rc1 tag and its tested on
> Broadcom NorthStar2 SoC.
>
> The patch set can be fetched from iproc-sha3-v2 branch
> of https://github.com/Broadcom/arm64-linux.git
>
> Changes since v1:
> - Renamed MODULE_ALIAS to MODULE_ALIAS_CRYPTO
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: caam: fix misspelled upper_32_bits
From: Herbert Xu @ 2016-06-20 11:34 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Horia Geantă, linux-crypto, linux-kernel
In-Reply-To: <20160616090609.1041337-1-arnd@arndb.de>
On Thu, Jun 16, 2016 at 11:05:46AM +0200, Arnd Bergmann wrote:
> An endianess fix mistakenly used higher_32_bits() instead of
> upper_32_bits(), and that doesn't exist:
>
> drivers/crypto/caam/desc_constr.h: In function 'append_ptr':
> drivers/crypto/caam/desc_constr.h:84:75: error: implicit declaration of function 'higher_32_bits' [-Werror=implicit-function-declaration]
> *offset = cpu_to_caam_dma(ptr);
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness")
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto : async implementation for sha1-mb
From: Herbert Xu @ 2016-06-20 11:21 UTC (permalink / raw)
To: Megha Dey
Cc: tim.c.chen, davem, linux-crypto, linux-kernel, fenghua.yu,
Megha Dey
In-Reply-To: <1466191710-2261-1-git-send-email-megha.dey@intel.com>
On Fri, Jun 17, 2016 at 12:28:30PM -0700, Megha Dey wrote:
>
> -static void sha1_mb_async_exit_tfm(struct crypto_tfm *tfm)
> -{
> - struct sha1_mb_ctx *ctx = crypto_tfm_ctx(tfm);
> + ahash_request_set_tfm(areq, child);
> + ahash_request_set_callback(areq, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
You need to fix them all, not just the one that I picked out.
> @@ -874,11 +893,13 @@ static struct ahash_alg sha1_mb_async_alg = {
> .cra_name = "sha1",
> .cra_driver_name = "sha1_mb",
> .cra_priority = 200,
> - .cra_flags = CRYPTO_ALG_TYPE_AHASH | CRYPTO_ALG_ASYNC,
> + .cra_flags = CRYPTO_ALG_TYPE_AHASH |
> + CRYPTO_ALG_ASYNC,
Please don't include unrelated changes such as white-space fixes
like this.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v9 2/3] crypto: kpp - Add DH software implementation
From: Herbert Xu @ 2016-06-20 11:15 UTC (permalink / raw)
To: Salvatore Benedetto; +Cc: linux-crypto
In-Reply-To: <1466174265-4546-3-git-send-email-salvatore.benedetto@intel.com>
On Fri, Jun 17, 2016 at 03:37:44PM +0100, Salvatore Benedetto wrote:
> * Implement MPI based Diffie-Hellman under kpp API
>
> +struct dh {
> + void *key;
> + void *p;
> + void *g;
> + unsigned int key_size;
> + unsigned int p_size;
> + unsigned int g_size;
> +};
> +
> +int crypto_dh_key_len(const struct dh *params);
> +int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params);
> +int crypto_dh_decode_key(const char *buf, unsigned int len, struct dh **params);
While you're at it, it would be nice if you could make the encoded
format little-endian, that way we can make test vectors for all
kpp algorithms use the same format.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v9 2/3] crypto: kpp - Add DH software implementation
From: Herbert Xu @ 2016-06-20 11:13 UTC (permalink / raw)
To: Salvatore Benedetto; +Cc: linux-crypto
In-Reply-To: <1466174265-4546-3-git-send-email-salvatore.benedetto@intel.com>
On Fri, Jun 17, 2016 at 03:37:44PM +0100, Salvatore Benedetto wrote:
>
> +int crypto_dh_encode_key(char *buf, unsigned int len, const struct dh *params)
> +{
> + struct kpp_secret *secret = (struct kpp_secret *)buf;
You can't do that. The memory under buf may not be aligned so
you need to copy it.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v8 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks
From: Herbert Xu @ 2016-06-20 10:54 UTC (permalink / raw)
To: Tudor Ambarus; +Cc: linux-crypto, horia.geanta
In-Reply-To: <1466002364-16945-2-git-send-email-tudor-dan.ambarus@nxp.com>
On Wed, Jun 15, 2016 at 05:52:42PM +0300, Tudor Ambarus wrote:
> This patch adds the function scatterwalk_sg_copychunks which writes
> a chunk of data from a scatterwalk to another scatterwalk.
> It will be used by caam driver to remove the leading zeros
> for the output data of the RSA algorithm, after the computation completes.
>
> Signed-off-by: Tudor Ambarus <tudor-dan.ambarus@nxp.com>
Not only does dropping leading zeroes lead to questions about
information leaks, but it makes every one of our RSA drivers
look crap.
So I'm going to change this and make it not skip leading zeroes.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v5 0/7] /dev/random - a new approach
From: Pavel Machek @ 2016-06-20 8:27 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert, Theodore Tso, Andi Kleen, sandyinchina, Jason Cooper,
John Denker, H. Peter Anvin, Joe Perches, George Spelvin,
linux-crypto, linux-kernel
In-Reply-To: <3817952.8FvMDE0Kc7@tauon.atsec.com>
Hi!
> > On Sun 2016-06-19 17:58:41, Stephan Mueller wrote:
> > > 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.
> >
> > Dunno. It is very similar to existing rng, AFAICT. And at the very
> > least, constants in existing RNG could be tuned to provide "entropy at
> > the boot time".
>
> The key differences and thus my main concerns I have with the current design
> are the following items. If we would change them, it is an intrusive change.
> As of now, I have not seen that intrusive changes were accepted. This led me
> to develop a competing algorithm.
Well, intrusive changes are hard to do, but replacing whole subsystems
is even harder -- and rightly so.
> - There was a debate around my approach assuming one bit of entropy per
> received IRQ. I am really wondering about that discussion when there is a much
> bigger "forcast" problem with the legacy /dev/random: how can we credit HIDs
> up to 11 bits of entropy when the user (a potential adversary) triggers these
> events? I am sure I would be shot down with such an approach if I would
> deliver that with a new implementation.
Well, if you can demonstrate 11 bits is too much, go ahead... I'm sure
that is rather easy to adjust.
But I believe that 1) user is not normally an adversary and 2) the
best thing for him to do would still be "pressing nothing". It will be
hard to press keys (etc) with great enough precision...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
From: Herbert Xu @ 2016-06-20 5:19 UTC (permalink / raw)
To: Theodore Ts'o, Linux Kernel Developers List, linux-crypto,
smueller, andi, sandyinchina, jsd, hpa
In-Reply-To: <20160620050203.GC9848@thunk.org>
On Mon, Jun 20, 2016 at 01:02:03AM -0400, Theodore Ts'o wrote:
>
> It's work that I'm not convinced is worth the gain? Perhaps I
> shouldn't have buried the lede, but repeating a paragraph from later
> in the message:
>
> So even if the AVX optimized is 100% faster than the generic version,
> it would change the time needed to create a 256 byte session key from
> 1.68 microseconds to 1.55 microseconds. And this is ignoring the
> extra overhead needed to set up AVX, the fact that this will require
> the kernel to do extra work doing the XSAVE and XRESTORE because of
> the use of the AVX registers, etc.
We do have figures on the efficiency of the accelerated chacha
implementation on 256-byte requests (I've picked the 8-block
version):
testing speed of chacha20 (chacha20-generic) encryption
test 2 (256 bit key, 256 byte blocks): 12702056 operations in 10 seconds (3251726336 bytes)
testing speed of chacha20 (chacha20-simd) encryption
test 2 (256 bit key, 256 byte blocks): 33028112 operations in 10 seconds (8455196672 bytes)
So it is a little bit more than 100%.
> So in the absolute best case, this improves the time needed to create
> a 256 bit session key by 0.13 microseconds. And that assumes that the
> extra setup and teardown overhead of an AVX optimized ChaCha20
> (including the XSAVE and XRESTORE of the AVX registers, etc.) don't
> end up making the CRNG **slower**.
The figures above include all of these overheads. The overheads
really only show up on 16-byte requests.
> P.S. I haven't measured this to see, mainly because I really don't
> care about the difference between 1.68 vs 1.55 microseconds, but there
> is a good chance in the crypto layer that it might be a good idea to
> have the system be smart enough to automatically fall back to using
> the **non** optimized version if you only need to encrypt a small
> amount of data.
You're right. chacha20-simd should use the generic version on
16-byte requests which is the only place where it is slower.
Something like this:
---8<---
Subject: crypto: chacha20-simd - Use generic code for small requests
On 16-byte requests the optimised version is actually slower than
the generic code, so we should simply use that instead.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/arch/x86/crypto/chacha20_glue.c b/arch/x86/crypto/chacha20_glue.c
index 2d5c2e0b..f910d1d 100644
--- a/arch/x86/crypto/chacha20_glue.c
+++ b/arch/x86/crypto/chacha20_glue.c
@@ -70,7 +70,7 @@ static int chacha20_simd(struct blkcipher_desc *desc, struct scatterlist *dst,
struct blkcipher_walk walk;
int err;
- if (!may_use_simd())
+ if (nbytes <= CHACHA20_BLOCK_SIZE || !may_use_simd())
return crypto_chacha20_crypt(desc, dst, src, nbytes);
state = (u32 *)roundup((uintptr_t)state_buf, CHACHA20_STATE_ALIGN);
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH v5 0/7] /dev/random - a new approach
From: Stephan Mueller @ 2016-06-20 5:51 UTC (permalink / raw)
To: Pavel Machek
Cc: herbert, Theodore Tso, Andi Kleen, sandyinchina, Jason Cooper,
John Denker, H. Peter Anvin, Joe Perches, George Spelvin,
linux-crypto, linux-kernel
In-Reply-To: <20160619193614.GA26146@amd>
Am Sonntag, 19. Juni 2016, 21:36:14 schrieb Pavel Machek:
Hi Pavel,
> On Sun 2016-06-19 17:58:41, Stephan Mueller wrote:
> > 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.
>
> Dunno. It is very similar to existing rng, AFAICT. And at the very
> least, constants in existing RNG could be tuned to provide "entropy at
> the boot time".
The key differences and thus my main concerns I have with the current design
are the following items. If we would change them, it is an intrusive change.
As of now, I have not seen that intrusive changes were accepted. This led me
to develop a competing algorithm.
- Correlation of noise sources: as outlined in [1] chapter 1, the three noise
sources of the legacy /dev/random implementation have a high correlation. Such
correlation is due to the fact that a HID/disk event at the same time produces
an IRQ event. The time stamp (which deliver the majority of entropy) of both
events are correlated. I would think that the maintenance of the fast_pools
partially breaks that correlation to some degree though, yet how much the
correlation is broken is unknown.
- Awarding IRQs only 1/64th bit of entropy compared to HID and disk noise
sources is warranted due to the correlation. As I try to show, IRQs have a
much higher entropy rate than what they are credited currently. But we cannot
set that value higher due to the correlation issue. That means, currently we
prefer desktop machines over server type systems since servers usually have no
HID. In addition, with SSDs or virtio-disks the disk noise source is
deactivated (again, common use cases for servers). Hence, server environments
are heavily penalized. (Note, awarding IRQ events one bit of entropy is the
root cause why my approach claims to be seeded very fast during boot time.
Furthermore, as outlined in [1] chapter 1 and 2, IRQ events are entropic even
in virtual machines which implies that even in VMs, my approach works well.)
- I am not sure the current way of crediting entropy has anything to do with
its entropy. It just happen to underestimate our entropy so it does not hurt.
I see no sensible reason why the calculation of an entropy estimate rests on
the first/second and third derivation of the Jiffies -- the Jiffies hardly
deliver any entropy and therefore why should they be a basis for entropy
calculation?
- There was a debate around my approach assuming one bit of entropy per
received IRQ. I am really wondering about that discussion when there is a much
bigger "forcast" problem with the legacy /dev/random: how can we credit HIDs
up to 11 bits of entropy when the user (a potential adversary) triggers these
events? I am sure I would be shot down with such an approach if I would
deliver that with a new implementation.
- The delivery of entropic data from the input_pool to the (non)blocking_pools
is not atomic (for the lack of better word), i.e. one block of data with a
given entropy content is injected into the (non)blocking_pool where the output
pool is still locked (the user cannot obtain data during that injection time).
With Ted's new patch set, two 64 bit blocks from the fast_pools are injected
into the ChaCha20 DRNG. So, it is clearly better than previously. But still,
with the blocking_pool, we face that issue. The reason for that issue is
outlined in [1] 2.1. In the pathological case with an active attack,
/dev/random could have a security strength of 2 * 128 bits of and not 2^128
bits when reading 128 bits out of it (the numbers are for illustration only,
it is a bit better as /dev/random is woken up at random_read_wakeup_bits
intervals -- but that number can be set to dangerous low levels down to 8
bits).
[1] http://www.chronox.de/lrng/doc/lrng.pdf
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
From: Theodore Ts'o @ 2016-06-20 5:02 UTC (permalink / raw)
To: Herbert Xu
Cc: Linux Kernel Developers List, linux-crypto, smueller, andi,
sandyinchina, jsd, hpa
In-Reply-To: <20160620012528.GA7471@gondor.apana.org.au>
On Mon, Jun 20, 2016 at 09:25:28AM +0800, Herbert Xu wrote:
> > Yes, I understand the argument that the networking stack is now
> > requiring the crypto layer --- but not all IOT devices may necessarily
> > require the IP stack (they might be using some alternate wireless
> > communications stack) and I'd much rather not make things worse.
>
> Sure, but 99% of the kernels out there will have a crypto API.
> So why not use it if it's there and use the standalone chacha
> code otherwise?
It's work that I'm not convinced is worth the gain? Perhaps I
shouldn't have buried the lede, but repeating a paragraph from later
in the message:
So even if the AVX optimized is 100% faster than the generic version,
it would change the time needed to create a 256 byte session key from
1.68 microseconds to 1.55 microseconds. And this is ignoring the
extra overhead needed to set up AVX, the fact that this will require
the kernel to do extra work doing the XSAVE and XRESTORE because of
the use of the AVX registers, etc.
So in the absolute best case, this improves the time needed to create
a 256 bit session key by 0.13 microseconds. And that assumes that the
extra setup and teardown overhead of an AVX optimized ChaCha20
(including the XSAVE and XRESTORE of the AVX registers, etc.) don't
end up making the CRNG **slower**.
The thing to remember about these optimizations is that they are great
for bulk encryption, but that's not what the getrandom(2) and
get_random_bytes() are used for, in general. We don't need to create
multiple megabytes of random numbers at a time. We need to create
them 256 bits at a time, with anti-backtracking protections in
between. Think of this as the random number equivalent of artisinal
beer making, as opposed to Budweiser beer, which ferments the beer
literally in pipelines. :-)
Yes, Budweiser may be made more efficiently using continuous
fermentation --- but would you want to drink it? And if you have to
constantly start and stop the continuous fermentation pipeline, the net
result can actually be less efficient compared to doing it right in
the first place....
- Ted
P.S. I haven't measured this to see, mainly because I really don't
care about the difference between 1.68 vs 1.55 microseconds, but there
is a good chance in the crypto layer that it might be a good idea to
have the system be smart enough to automatically fall back to using
the **non** optimized version if you only need to encrypt a small
amount of data.
^ permalink raw reply
* Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
From: Herbert Xu @ 2016-06-20 1:25 UTC (permalink / raw)
To: Theodore Ts'o, Linux Kernel Developers List, linux-crypto,
smueller, andi, sandyinchina, jsd, hpa
In-Reply-To: <20160619231827.GB9848@thunk.org>
On Sun, Jun 19, 2016 at 07:18:28PM -0400, Theodore Ts'o wrote:
>
> C) Simply compiling in the Crypto layer and the ChaCha20 generic
> handling (all of which is doing extra work which we would then be
> undoing in the random layer --- and I haven't included the extra code
> in the random driver needed interface with the crypto layer) costs an
> extra 20k. That's roughly the amount of extra kernel bloat that the
> Linux kernel grew in its allnoconfig from version to version from 3.0
> to 3.16. I don't have the numbers from the more recent kernels, but
> roughly speaking, we would be responsible for **all** of the extra
> kernel bloat (and if there was any extra kernel bloat, we would
> helping to double it) in the kernel release where this code would go
> in. I suspect the folks involved with the kernel tinificaiton efforts
> wouldn't exactly be pleased with this.
>
> Yes, I understand the argument that the networking stack is now
> requiring the crypto layer --- but not all IOT devices may necessarily
> require the IP stack (they might be using some alternate wireless
> communications stack) and I'd much rather not make things worse.
Sure, but 99% of the kernels out there will have a crypto API.
So why not use it if it's there and use the standalone chacha
code otherwise?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
From: Theodore Ts'o @ 2016-06-19 23:18 UTC (permalink / raw)
To: Herbert Xu
Cc: Linux Kernel Developers List, linux-crypto, smueller, andi,
sandyinchina, jsd, hpa
In-Reply-To: <20160615145908.GA18866@gondor.apana.org.au>
On Wed, Jun 15, 2016 at 10:59:08PM +0800, Herbert Xu wrote:
> I think you should be accessing this through the crypto API rather
> than going direct. We already have at least one accelerated
> implementation of chacha20 and there may well be more of them
> in future. Going through the crypto API means that you will
> automatically pick up the best implementation for the platform.
While there are some benefits of going through the crypto API, there
are some downsides as well:
A) Unlike using ChaCha20 in cipher mode, only need the keystream, and
we don't need to XOR the output with plaintext. We could supply a
dummy zero-filled buffer to archive the same result, but now the
"accelerated" version is having to do an extra memory reference. Even
if the L1 cache is big enough so that we're not going all the way out
to DRAM, we're putting additional pressure the D cache.
B) The anti-backtracking feature involves taking the existing key and
XOR'ing it with unsued output from the keystream. We can't do that
using the Crypto API without keeping our own copy of the key, and then
calling setkey --- which means yet more extra memory references.
C) Simply compiling in the Crypto layer and the ChaCha20 generic
handling (all of which is doing extra work which we would then be
undoing in the random layer --- and I haven't included the extra code
in the random driver needed interface with the crypto layer) costs an
extra 20k. That's roughly the amount of extra kernel bloat that the
Linux kernel grew in its allnoconfig from version to version from 3.0
to 3.16. I don't have the numbers from the more recent kernels, but
roughly speaking, we would be responsible for **all** of the extra
kernel bloat (and if there was any extra kernel bloat, we would
helping to double it) in the kernel release where this code would go
in. I suspect the folks involved with the kernel tinificaiton efforts
wouldn't exactly be pleased with this.
Yes, I understand the argument that the networking stack is now
requiring the crypto layer --- but not all IOT devices may necessarily
require the IP stack (they might be using some alternate wireless
communications stack) and I'd much rather not make things worse.
The final thing is that it's not at all clear that the accelerated
implementation is all that important anyway. Consider the following
two results using the unaccelerated ChaCha20:
% dd if=/dev/urandom bs=4M count=32 of=/dev/null
32+0 records in
32+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 1.18647 s, 113 MB/s
% dd if=/dev/urandom bs=32 count=4194304 of=/dev/null
4194304+0 records in
4194304+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 7.08294 s, 18.9 MB/s
So in both cases, we are reading 128M from the CRNG. In the first
case, we see the sort of speed we would get if we were using the CRNG
for some illegitimate, such as "dd if=/dev/urandom of=/dev/sdX bs=4M"
(because they were too lazy to type "apt-get install nwipe").
In the second case, we see the use of /dev/urandom in a much more
reasonable, proper, real-world use case for /de/urandom, which is some
userspace process needing a 256 bit session key for a TLS connection,
or some such. In this case, we see that the other overheads of
providing the anti-backtracking protection, system call overhead,
etc., completely dominate the speed of the core crypto primitive.
So even if the AVX optimized is 100% faster than the generic version,
it would change the time needed to create a 256 byte session key from
1.68 microseconds to 1.55 microseconds. And this is ignoring the
extra overhead needed to set up AVX, the fact that this will require
the kernel to do extra work doing the XSAVE and XRESTORE because of
the use of the AVX registers, etc.
The bottom line is that optimized ChaCha20 optimizations might be
great for bulk encryption, but for the purposes of generating 256 byte
session keys, I don't think the costs outweigh the benefits.
Cheers,
- Ted
^ permalink raw reply
* Re: [PATCH v5 0/7] /dev/random - a new approach
From: Sandy Harris @ 2016-06-19 20:47 UTC (permalink / raw)
To: Pavel Machek
Cc: Stephan Mueller, Herbert Xu, Theodore Tso, Andi Kleen,
Jason Cooper, John Denker, H. Peter Anvin, Joe Perches,
George Spelvin, linux-crypto, LKML
In-Reply-To: <20160619193614.GA26146@amd>
On Sun, Jun 19, 2016 at 3:36 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> The following patch set provides a different approach to /dev/random ...
>
> Dunno. It is very similar to existing rng, AFAICT.
I do not think so. A lot of the basic principles are the same of course,
but Stephan is suggesting some real changes. On the other hand, I'm
not sure all of them are good ideas & Ted has already incorporated
some into the driver, so it is debatable how much here is really useful.
> And at the very least, constants in existing RNG could be tuned
> to provide "entropy at the boot time".
No, this is a rather hard problem & just tweaking definitely will
not solve it. Ted's patches, Stephan's, mine, the grsecurity
stuff and the kernel hardening project all have things that
might help, but as far as I can see there is no complete
in-kernel solution yet.
Closest thing I have seen to a solution are Denker's suggestions at:
http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
Those, though, require changes to build & installation methods
& it might be hard to get distros & device vendors to do it.
> So IMO this should be re-done as tweaks to existing design, not as
> completely new RNG.
I agree, & I think Stephan has already done some of that.
^ permalink raw reply
* Re: [PATCH v5 0/7] /dev/random - a new approach
From: Pavel Machek @ 2016-06-19 19:36 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert, Theodore Tso, Andi Kleen, sandyinchina, Jason Cooper,
John Denker, H. Peter Anvin, Joe Perches, George Spelvin,
linux-crypto, linux-kernel
In-Reply-To: <2754489.L1QYabbYUc@positron.chronox.de>
On Sun 2016-06-19 17:58:41, Stephan Mueller wrote:
> 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.
Dunno. It is very similar to existing rng, AFAICT. And at the very
least, constants in existing RNG could be tuned to provide "entropy at
the boot time".
So IMO this should be re-done as tweaks to existing design, not as
completely new RNG.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH v5 3/7] crypto: Linux Random Number Generator
From: Stephan Mueller @ 2016-06-19 18:31 UTC (permalink / raw)
To: Andi Kleen
Cc: herbert, Theodore Tso, sandyinchina, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, Pavel Machek, George Spelvin,
linux-crypto, linux-kernel
In-Reply-To: <20160619165854.GO13997@two.firstfloor.org>
Am Sonntag, 19. Juni 2016, 09:58:55 schrieb Andi Kleen:
Hi Andi,
> On Sun, Jun 19, 2016 at 06:00:21PM +0200, Stephan Mueller wrote:
> > The LRNG with all its properties is documented in [1]. This
> > documentation covers the functional discussion as well as testing of all
> > aspects of entropy processing. 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.
> >
> > [1] http://www.chronox.de/lrng.html
>
> A web site is not a replacement for a proper commit message.
I will provide a complete commit message in the next round.
Thanks.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v5 3/7] crypto: Linux Random Number Generator
From: Andi Kleen @ 2016-06-19 16:58 UTC (permalink / raw)
To: Stephan Mueller
Cc: herbert, Theodore Tso, Andi Kleen, sandyinchina, Jason Cooper,
John Denker, H. Peter Anvin, Joe Perches, Pavel Machek,
George Spelvin, linux-crypto, linux-kernel
In-Reply-To: <1627227.URpHt84zDf@positron.chronox.de>
On Sun, Jun 19, 2016 at 06:00:21PM +0200, Stephan Mueller wrote:
> The LRNG with all its properties is documented in [1]. This
> documentation covers the functional discussion as well as testing of all
> aspects of entropy processing. 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.
>
> [1] http://www.chronox.de/lrng.html
A web site is not a replacement for a proper commit message.
-Anid
^ permalink raw reply
* [PATCH v5 0/7] /dev/random - a new approach
From: Stephan Mueller @ 2016-06-19 15:58 UTC (permalink / raw)
To: herbert, Theodore Tso
Cc: Andi Kleen, sandyinchina, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, Pavel Machek, George Spelvin,
linux-crypto, linux-kernel
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 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 data obtained
during shutdown of the previous boot (i.e. the requirement phrased by the
legacy /dev/random implementation). As the writing of the random data into
/dev/random by user space will happen before any cryptographic service
is initialized in user space, this test demonstrates that sufficient
entropy is already present in the LRNG at the time user space requires it
for seeding cryptographic daemons. Note, this test result was obtained
for different architectures, such as x86 64 bit, x86 32 bit, ARM 32 bit and
MIPS 32 bit.
[1] http://www.chronox.de/lrng/doc/lrng.pdf
[2] http://www.chronox.de/lrng.html
Stephan Mueller (7):
crypto: DRBG - externalize DRBG functions for LRNG
random: conditionally compile code depending on LRNG
crypto: Linux Random Number Generator
crypto: LRNG - enable compile
random: add interrupt callback to VMBus IRQ handler
crypto: isolate the chacha20_block function
crypto: LRNG - add ChaCha20 support
crypto/Kconfig | 15 +
crypto/Makefile | 8 +
crypto/chacha20_block.c | 79 ++
crypto/chacha20_generic.c | 61 --
crypto/drbg.c | 11 +-
crypto/lrng_base.c | 1942 +++++++++++++++++++++++++++++++++++++++++++++
crypto/lrng_kcapi.c | 167 ++++
crypto/lrng_standalone.c | 218 +++++
drivers/char/random.c | 9 +
drivers/hv/vmbus_drv.c | 3 +
include/crypto/chacha20.h | 1 +
include/crypto/drbg.h | 7 +
include/linux/genhd.h | 5 +
include/linux/random.h | 7 +-
14 files changed, 2465 insertions(+), 68 deletions(-)
create mode 100644 crypto/chacha20_block.c
create mode 100644 crypto/lrng_base.c
create mode 100644 crypto/lrng_kcapi.c
create mode 100644 crypto/lrng_standalone.c
--
2.5.5
^ permalink raw reply
* [PATCH v5 2/7] random: conditionally compile code depending on LRNG
From: Stephan Mueller @ 2016-06-19 15:59 UTC (permalink / raw)
To: herbert
Cc: Theodore Tso, Andi Kleen, sandyinchina, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, Pavel Machek, George Spelvin,
linux-crypto, linux-kernel
In-Reply-To: <2754489.L1QYabbYUc@positron.chronox.de>
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 <smueller@chronox.de>
---
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 0158d3b..ef89c0e 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -268,6 +268,8 @@
#include <asm/irq_regs.h>
#include <asm/io.h>
+#ifndef CONFIG_CRYPTO_LRNG
+
#define CREATE_TRACE_POINTS
#include <trace/events/random.h>
@@ -1621,6 +1623,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
}
return urandom_read(NULL, buf, count, NULL);
}
+#endif /* CONFIG_CRYPTO_LRNG */
/********************************************************************
*
@@ -1628,6 +1631,7 @@ SYSCALL_DEFINE3(getrandom, char __user *, buf, size_t, count,
*
********************************************************************/
+#ifndef CONFIG_CRYPTO_LRNG
#ifdef CONFIG_SYSCTL
#include <linux/sysctl.h>
@@ -1765,6 +1769,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)
@@ -1840,6 +1846,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.
@@ -1859,3 +1866,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 359a8e4..24cfb99 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -433,8 +433,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 e47e533..8773dfc 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.5.5
^ permalink raw reply related
* [PATCH v5 1/7] crypto: DRBG - externalize DRBG functions for LRNG
From: Stephan Mueller @ 2016-06-19 15:59 UTC (permalink / raw)
To: herbert
Cc: Theodore Tso, Andi Kleen, sandyinchina, Jason Cooper, John Denker,
H. Peter Anvin, Joe Perches, Pavel Machek, George Spelvin,
linux-crypto, linux-kernel
In-Reply-To: <2754489.L1QYabbYUc@positron.chronox.de>
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 <smueller@chronox.de>
---
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 ded8638..6f968e3 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.5.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox