* Re: [PATCH v2 2/3] crypto: arm64/chacha20 - implement NEON version based on SSE3 code
From: Herbert Xu @ 2016-12-27 9:00 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <1481294033-23508-3-git-send-email-ard.biesheuvel@linaro.org>
On Fri, Dec 09, 2016 at 02:33:52PM +0000, Ard Biesheuvel wrote:
>
> + .chunksize = 4 * CHACHA20_BLOCK_SIZE,
This should use a new attribute specific to the walk interface.
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] crypto: arm64/aes: reimplement bit-sliced ARM/NEON implementation for arm64
From: Herbert Xu @ 2016-12-27 9:03 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel, nico, will.deacon
In-Reply-To: <1481564758-7275-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Dec 12, 2016 at 05:45:58PM +0000, Ard Biesheuvel wrote:
>
> + .chunksize = 8 * AES_BLOCK_SIZE,
Same comment as to the previous patches regarding chunksize.
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 v2 7/7] hwrng: core: Remove linux/sched.h from includes
From: Herbert Xu @ 2016-12-27 9:14 UTC (permalink / raw)
To: Corentin Labbe; +Cc: mpm, arnd, gregkh, linux-crypto, linux-kernel
In-Reply-To: <20161213145115.30082-7-clabbe.montjoie@gmail.com>
On Tue, Dec 13, 2016 at 03:51:15PM +0100, Corentin Labbe wrote:
> linux/sched.h is useless for hw_random/core.c.
> This patch remove it.
I see a schedule_timeout_interruptible call in core.c.
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: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
From: Herbert Xu @ 2016-12-27 9:02 UTC (permalink / raw)
To: Jan Glauber
Cc: linux-crypto, linux-kernel, David S . Miller, Mahipal Challa,
Vishnu Nair
In-Reply-To: <20161212150439.18627-1-jglauber@cavium.com>
Hi Jan:
On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote:
>
> this series adds support for hardware accelerated compression & decompression
> as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally
> for some time and would like to get feedback on the RFC to see if this goes
> into the right direction and to see if there are any concerns.
>
> We've discussed switching to the new acomp algorithm but for the time being
> decided against acomp because our test cases are not yet supported with it.
OK. Do you see any major problems in converting this over to acomp?
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
* Crypto Fixes for 4.10
From: Herbert Xu @ 2016-12-27 9:45 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20161215160732.GA16580@gondor.apana.org.au>
Hi Linus:
This push fixes a hash corruption bug in the marvell driver.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Romain Perier (1):
crypto: marvell - Copy IVDIG before launching partial DMA ahash requests
drivers/crypto/marvell/cesa.h | 3 ++-
drivers/crypto/marvell/hash.c | 34 +++++++++++++++++++++++++++++++++-
drivers/crypto/marvell/tdma.c | 9 ++++++++-
3 files changed, 43 insertions(+), 3 deletions(-)
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: [sparc64] cryptomgr_test OOPS kernel 4.9.0+
From: Herbert Xu @ 2016-12-27 9:52 UTC (permalink / raw)
To: David Miller; +Cc: matorola, linux-crypto, sparclinux, giovanni.cabiddu
In-Reply-To: <20161226.172619.1321397093716823099.davem@davemloft.net>
On Mon, Dec 26, 2016 at 05:26:19PM -0500, David Miller wrote:
> From: Anatoly Pugachev <matorola@gmail.com>
> Date: Sun, 25 Dec 2016 20:56:08 +0300
>
> > Disabling kernel config option
> > CRYPTO_MANAGER_DISABLE_TESTS
> > i.e. enable run-time self tests, makes kernel unbootable:
> >
> > tested with git kernels v4.9-8648-g5cc60aeedf31 and v4.9-12259-g7c0f6ba682b9
>
> I think the testing code for the new synchronous compression module is
> putting kernel image pointers into scatterlists, which in turn we
> attempt to transform to and from page structs.
>
> That doesn't work.
>
> It's coming from the test input buffers:
>
> static int test_acomp(struct crypto_acomp *tfm, struct comp_testvec *ctemplate,
> struct comp_testvec *dtemplate, int ctcount, int dtcount)
> {
> ...
> sg_init_one(&src, ctemplate[i].input, ilen);
>
> These have to be copied into kmalloc() buffers or similar, just like
> the skchiper tests do.
>
> The crash on sparc64 shows that we try to dereference a page struct at
> a bogus vmemmap address for a page that doesn't exist.
>
> I hacked up the following and this makes the crashes go away:
Thanks Dave. I've just applied the patch
https://patchwork.kernel.org/patch/9483763/
which should fix this.
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: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash
From: Herbert Xu @ 2016-12-27 9:58 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Ard Biesheuvel, Andy Lutomirski, Daniel Borkmann, Netdev, LKML,
Linux Crypto Mailing List, Jason A. Donenfeld,
Hannes Frederic Sowa, Alexei Starovoitov, Eric Dumazet,
Eric Biggers, Tom Herbert, David S. Miller
In-Reply-To: <CALCETrXFTQ2AXgbQzPnRcDRHK81=FS1R0zqfoTqGjUsqZy2PvQ@mail.gmail.com>
On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>
> According to Daniel, the networking folks want to let embedded systems
> include BPF without requiring the crypto core.
Last I checked the IPv4 stack depended on the crypto API so this
sounds bogus.
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 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Herbert Xu @ 2016-12-27 10:04 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <1481207339-17332-1-git-send-email-ard.biesheuvel@linaro.org>
On Thu, Dec 08, 2016 at 02:28:57PM +0000, Ard Biesheuvel wrote:
> Another port of existing x86 SSE code to NEON, again both for arm64 and ARM.
>
> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be
> an efficient software implementable 'standby cipher', in case AES cannot
> be used.
>
> This NEON implementation is almost 2x as fast as the generic C code
> (measured on Cortex-A57 using the arm64 version)
>
> I'm aware that blkciphers are deprecated in favor of skciphers, but this
> code (like the x86 version) uses the init and setkey routines of the generic
> version, so it is probably better to port all implementations at once.
>
> Ard Biesheuvel (2):
> crypto: arm64/chacha20 - implement NEON version based on SSE3 code
> crypto: arm/chacha20 - implement NEON version based on SSE3 code
Both patches 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 v2 1/3] crypto: chacha20 - convert generic and x86 versions to skcipher
From: Herbert Xu @ 2016-12-27 10:04 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <1481294033-23508-2-git-send-email-ard.biesheuvel@linaro.org>
On Fri, Dec 09, 2016 at 02:33:51PM +0000, Ard Biesheuvel wrote:
> This converts the ChaCha20 code from a blkcipher to a skcipher, which
> is now the preferred way to implement symmetric block and stream ciphers.
>
> This ports the generic and x86 versions at the same time because the
> latter reuses routines of the former.
>
> Note that the skcipher_walk() API guarantees that all presented blocks
> except the final one are a multiple of the chunk size, so we can simplify
> the encrypt() routine somewhat.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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: bring back alphabetical order of Makefile
From: Herbert Xu @ 2016-12-27 10:05 UTC (permalink / raw)
To: Corentin Labbe; +Cc: davem, linux-crypto, linux-kernel
In-Reply-To: <20161213143059.13543-1-clabbe.montjoie@gmail.com>
On Tue, Dec 13, 2016 at 03:30:59PM +0100, Corentin Labbe wrote:
> THe major content of drivers/crypto/Makefile is sorted, only recent
> addition break this sort.
>
> This patch bring back this alphabetical sorting.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.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: aesni-intel - RFC4106 can zero copy when !PageHighMem
From: Herbert Xu @ 2016-12-27 10:05 UTC (permalink / raw)
To: Ilya Lesokhin; +Cc: linux-crypto, tadeusz.struk, davejwatson, tls-fpga-sw-dev
In-Reply-To: <1481639526-71743-1-git-send-email-ilyal@mellanox.com>
On Tue, Dec 13, 2016 at 04:32:06PM +0200, Ilya Lesokhin wrote:
> In the common case of !PageHighMem we can do zero copy crypto
> even if sg crosses a pages boundary.
>
> Signed-off-by: Ilya Lesokhin <ilyal@mellanox.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 v2 1/7] hwrng: core: do not use multiple blank lines
From: Herbert Xu @ 2016-12-27 10:05 UTC (permalink / raw)
To: Corentin Labbe; +Cc: mpm, arnd, gregkh, linux-crypto, linux-kernel
In-Reply-To: <20161213145115.30082-1-clabbe.montjoie@gmail.com>
On Tue, Dec 13, 2016 at 03:51:09PM +0100, Corentin Labbe wrote:
> This patch fix the checkpatch warning "Please don't use multiple blank lines"
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Patches 1-6 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 -resend with CC] crypto: algif_hash, avoid zero-sized array
From: Herbert Xu @ 2016-12-27 10:06 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-crypto, linux-kernel, David S. Miller
In-Reply-To: <20161215133101.6129-1-jslaby@suse.cz>
On Thu, Dec 15, 2016 at 02:31:01PM +0100, Jiri Slaby wrote:
> With this reproducer:
> struct sockaddr_alg alg = {
> .salg_family = 0x26,
> .salg_type = "hash",
> .salg_feat = 0xf,
> .salg_mask = 0x5,
> .salg_name = "digest_null",
> };
> int sock, sock2;
>
> sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
> bind(sock, (struct sockaddr *)&alg, sizeof(alg));
> sock2 = accept(sock, NULL, NULL);
> setsockopt(sock, SOL_ALG, ALG_SET_KEY, "\x9b\xca", 2);
> accept(sock2, NULL, NULL);
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 v3 0/2] Add MediaTek crypto accelerator driver
From: Herbert Xu @ 2016-12-27 10:06 UTC (permalink / raw)
To: Ryder Lee
Cc: David S. Miller, Matthias Brugger, devicetree, linux-mediatek,
linux-kernel, linux-crypto, linux-arm-kernel, Sean Wang, Roy Luo
In-Reply-To: <1482114045-18716-1-git-send-email-ryder.lee@mediatek.com>
On Mon, Dec 19, 2016 at 10:20:43AM +0800, Ryder Lee wrote:
> Hello,
>
> This adds support for the MediaTek hardware accelerator on
> some SoCs.
>
> This driver currently implement:
> - SHA1 and SHA2 family(HMAC) hash algorithms.
> - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
>
> Chances since v3:
> -remove unused structure member
> -drop interrupt-parent from DT bindings documentation
>
> Changes since v2:
> - use byteorder conversion macros and type identifiers for descriptors
> - revise register definition macros to make it more clear
> - revise DT compatiable string
>
> Changes since v1:
> - remove EXPORT_SYMBOL
> - remove unused PRNG setting
> - sort headers in alphabetical order
> - add a definition for IRQ unmber
> - replace ambiguous definition
> - add more annotation and function comment
> - add COMPILE_TEST in Kconfig
>
> Ryder Lee (2):
> Add crypto driver support for some MediaTek chips
> crypto: mediatek - add DT bindings documentation
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: [PATCHv2] crypto: testmgr: Use heap buffer for acomp test input
From: Herbert Xu @ 2016-12-27 10:06 UTC (permalink / raw)
To: Laura Abbott
Cc: David S. Miller, Ard Biesheuvel, Giovanni Cabiddu, linux-crypto,
linux-kernel, linux-arm-kernel, Mark Rutland,
Christopher Covington
In-Reply-To: <1482352374-22750-1-git-send-email-labbott@redhat.com>
On Wed, Dec 21, 2016 at 12:32:54PM -0800, Laura Abbott wrote:
>
> Christopher Covington reported a crash on aarch64 on recent Fedora
> kernels:
>
> kernel BUG at ./include/linux/scatterlist.h:140!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162
> Hardware name: linux,dummy-virt (DT)
> task: ffff80007c650080 task.stack: ffff800008910000
> PC is at sg_init_one+0xa0/0xb8
> LR is at sg_init_one+0x24/0xb8
> ...
> [<ffff000008398db8>] sg_init_one+0xa0/0xb8
> [<ffff000008350a44>] test_acomp+0x10c/0x438
> [<ffff000008350e20>] alg_test_comp+0xb0/0x118
> [<ffff00000834f28c>] alg_test+0x17c/0x2f0
> [<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
> [<ffff0000080dac70>] kthread+0xf8/0x128
> [<ffff000008082ec0>] ret_from_fork+0x10/0x50
>
> The test vectors used for input are part of the kernel image. These
> inputs are passed as a buffer to sg_init_one which eventually blows up
> with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
> false for the kernel image since virt_to_page will not return the
> correct page. Fix this by copying the input vectors to heap buffer
> before setting up the scatterlist.
>
> Reported-by: Christopher Covington <cov@codeaurora.org>
> Fixes: d7db7a882deb ("crypto: acomp - update testmgr with support for acomp")
> Signed-off-by: Laura Abbott <labbott@redhat.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
* [cryptodev:master 4/17] arch/arm64/crypto/chacha20-neon-glue.c:66:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type
From: kbuild test robot @ 2016-12-27 12:27 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: kbuild-all, linux-crypto, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 6294 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: fb91a661d99f460f2ea4c7f23ed47f56863ca1d1
commit: 9ae433bc79f97bae221d53bb1a8e21415ea58625 [4/17] crypto: chacha20 - convert generic and x86 versions to skcipher
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
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
git checkout 9ae433bc79f97bae221d53bb1a8e21415ea58625
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
arch/arm64/crypto/chacha20-neon-glue.c: In function 'chacha20_simd':
>> arch/arm64/crypto/chacha20-neon-glue.c:66:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type [-Werror=incompatible-pointer-types]
return crypto_chacha20_crypt(desc, dst, src, nbytes);
^~~~
In file included from arch/arm64/crypto/chacha20-neon-glue.c:22:0:
include/crypto/chacha20.h:24:5: note: expected 'struct skcipher_request *' but argument is of type 'struct blkcipher_desc *'
int crypto_chacha20_crypt(struct skcipher_request *req);
^~~~~~~~~~~~~~~~~~~~~
>> arch/arm64/crypto/chacha20-neon-glue.c:66:10: error: too many arguments to function 'crypto_chacha20_crypt'
return crypto_chacha20_crypt(desc, dst, src, nbytes);
^~~~~~~~~~~~~~~~~~~~~
In file included from arch/arm64/crypto/chacha20-neon-glue.c:22:0:
include/crypto/chacha20.h:24:5: note: declared here
int crypto_chacha20_crypt(struct skcipher_request *req);
^~~~~~~~~~~~~~~~~~~~~
arch/arm64/crypto/chacha20-neon-glue.c: At top level:
>> arch/arm64/crypto/chacha20-neon-glue.c:109:15: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.setkey = crypto_chacha20_setkey,
^~~~~~~~~~~~~~~~~~~~~~
arch/arm64/crypto/chacha20-neon-glue.c:109:15: note: (near initialization for 'alg.cra_u.blkcipher.setkey')
cc1: some warnings being treated as errors
vim +/crypto_chacha20_crypt +66 arch/arm64/crypto/chacha20-neon-glue.c
8621caa0 Ard Biesheuvel 2016-12-08 60 {
8621caa0 Ard Biesheuvel 2016-12-08 61 struct blkcipher_walk walk;
8621caa0 Ard Biesheuvel 2016-12-08 62 u32 state[16];
8621caa0 Ard Biesheuvel 2016-12-08 63 int err;
8621caa0 Ard Biesheuvel 2016-12-08 64
8621caa0 Ard Biesheuvel 2016-12-08 65 if (nbytes <= CHACHA20_BLOCK_SIZE)
8621caa0 Ard Biesheuvel 2016-12-08 @66 return crypto_chacha20_crypt(desc, dst, src, nbytes);
8621caa0 Ard Biesheuvel 2016-12-08 67
8621caa0 Ard Biesheuvel 2016-12-08 68 blkcipher_walk_init(&walk, dst, src, nbytes);
8621caa0 Ard Biesheuvel 2016-12-08 69 err = blkcipher_walk_virt_block(desc, &walk, CHACHA20_BLOCK_SIZE);
8621caa0 Ard Biesheuvel 2016-12-08 70
8621caa0 Ard Biesheuvel 2016-12-08 71 crypto_chacha20_init(state, crypto_blkcipher_ctx(desc->tfm), walk.iv);
8621caa0 Ard Biesheuvel 2016-12-08 72
8621caa0 Ard Biesheuvel 2016-12-08 73 kernel_neon_begin();
8621caa0 Ard Biesheuvel 2016-12-08 74
8621caa0 Ard Biesheuvel 2016-12-08 75 while (walk.nbytes >= CHACHA20_BLOCK_SIZE) {
8621caa0 Ard Biesheuvel 2016-12-08 76 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr,
8621caa0 Ard Biesheuvel 2016-12-08 77 rounddown(walk.nbytes, CHACHA20_BLOCK_SIZE));
8621caa0 Ard Biesheuvel 2016-12-08 78 err = blkcipher_walk_done(desc, &walk,
8621caa0 Ard Biesheuvel 2016-12-08 79 walk.nbytes % CHACHA20_BLOCK_SIZE);
8621caa0 Ard Biesheuvel 2016-12-08 80 }
8621caa0 Ard Biesheuvel 2016-12-08 81
8621caa0 Ard Biesheuvel 2016-12-08 82 if (walk.nbytes) {
8621caa0 Ard Biesheuvel 2016-12-08 83 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr,
8621caa0 Ard Biesheuvel 2016-12-08 84 walk.nbytes);
8621caa0 Ard Biesheuvel 2016-12-08 85 err = blkcipher_walk_done(desc, &walk, 0);
8621caa0 Ard Biesheuvel 2016-12-08 86 }
8621caa0 Ard Biesheuvel 2016-12-08 87
8621caa0 Ard Biesheuvel 2016-12-08 88 kernel_neon_end();
8621caa0 Ard Biesheuvel 2016-12-08 89
8621caa0 Ard Biesheuvel 2016-12-08 90 return err;
8621caa0 Ard Biesheuvel 2016-12-08 91 }
8621caa0 Ard Biesheuvel 2016-12-08 92
8621caa0 Ard Biesheuvel 2016-12-08 93 static struct crypto_alg alg = {
8621caa0 Ard Biesheuvel 2016-12-08 94 .cra_name = "chacha20",
8621caa0 Ard Biesheuvel 2016-12-08 95 .cra_driver_name = "chacha20-neon",
8621caa0 Ard Biesheuvel 2016-12-08 96 .cra_priority = 300,
8621caa0 Ard Biesheuvel 2016-12-08 97 .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
8621caa0 Ard Biesheuvel 2016-12-08 98 .cra_blocksize = 1,
8621caa0 Ard Biesheuvel 2016-12-08 99 .cra_type = &crypto_blkcipher_type,
8621caa0 Ard Biesheuvel 2016-12-08 100 .cra_ctxsize = sizeof(struct chacha20_ctx),
8621caa0 Ard Biesheuvel 2016-12-08 101 .cra_alignmask = sizeof(u32) - 1,
8621caa0 Ard Biesheuvel 2016-12-08 102 .cra_module = THIS_MODULE,
8621caa0 Ard Biesheuvel 2016-12-08 103 .cra_u = {
8621caa0 Ard Biesheuvel 2016-12-08 104 .blkcipher = {
8621caa0 Ard Biesheuvel 2016-12-08 105 .min_keysize = CHACHA20_KEY_SIZE,
8621caa0 Ard Biesheuvel 2016-12-08 106 .max_keysize = CHACHA20_KEY_SIZE,
8621caa0 Ard Biesheuvel 2016-12-08 107 .ivsize = CHACHA20_IV_SIZE,
8621caa0 Ard Biesheuvel 2016-12-08 108 .geniv = "seqiv",
8621caa0 Ard Biesheuvel 2016-12-08 @109 .setkey = crypto_chacha20_setkey,
8621caa0 Ard Biesheuvel 2016-12-08 110 .encrypt = chacha20_simd,
8621caa0 Ard Biesheuvel 2016-12-08 111 .decrypt = chacha20_simd,
8621caa0 Ard Biesheuvel 2016-12-08 112 },
:::::: The code at line 66 was first introduced by commit
:::::: 8621caa0d45e731f2e9f5889ff5bb384fcd6e059 crypto: arm64/chacha20 - implement NEON version based on SSE3 code
:::::: TO: Ard Biesheuvel <ard.biesheuvel@linaro.org>
:::::: CC: Herbert Xu <herbert@gondor.apana.org.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 53488 bytes --]
^ permalink raw reply
* [cryptodev:master 4/17] arch/arm/crypto/chacha20-neon-glue.c:68:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type
From: kbuild test robot @ 2016-12-27 12:44 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: kbuild-all, linux-crypto, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 6289 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: fb91a661d99f460f2ea4c7f23ed47f56863ca1d1
commit: 9ae433bc79f97bae221d53bb1a8e21415ea58625 [4/17] crypto: chacha20 - convert generic and x86 versions to skcipher
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
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
git checkout 9ae433bc79f97bae221d53bb1a8e21415ea58625
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
arch/arm/crypto/chacha20-neon-glue.c: In function 'chacha20_simd':
>> arch/arm/crypto/chacha20-neon-glue.c:68:32: error: passing argument 1 of 'crypto_chacha20_crypt' from incompatible pointer type [-Werror=incompatible-pointer-types]
return crypto_chacha20_crypt(desc, dst, src, nbytes);
^~~~
In file included from arch/arm/crypto/chacha20-neon-glue.c:22:0:
include/crypto/chacha20.h:24:5: note: expected 'struct skcipher_request *' but argument is of type 'struct blkcipher_desc *'
int crypto_chacha20_crypt(struct skcipher_request *req);
^~~~~~~~~~~~~~~~~~~~~
>> arch/arm/crypto/chacha20-neon-glue.c:68:10: error: too many arguments to function 'crypto_chacha20_crypt'
return crypto_chacha20_crypt(desc, dst, src, nbytes);
^~~~~~~~~~~~~~~~~~~~~
In file included from arch/arm/crypto/chacha20-neon-glue.c:22:0:
include/crypto/chacha20.h:24:5: note: declared here
int crypto_chacha20_crypt(struct skcipher_request *req);
^~~~~~~~~~~~~~~~~~~~~
arch/arm/crypto/chacha20-neon-glue.c: At top level:
>> arch/arm/crypto/chacha20-neon-glue.c:111:15: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.setkey = crypto_chacha20_setkey,
^~~~~~~~~~~~~~~~~~~~~~
arch/arm/crypto/chacha20-neon-glue.c:111:15: note: (near initialization for 'alg.cra_u.blkcipher.setkey')
cc1: some warnings being treated as errors
vim +/crypto_chacha20_crypt +68 arch/arm/crypto/chacha20-neon-glue.c
80966672 Ard Biesheuvel 2016-12-08 62 {
80966672 Ard Biesheuvel 2016-12-08 63 struct blkcipher_walk walk;
80966672 Ard Biesheuvel 2016-12-08 64 u32 state[16];
80966672 Ard Biesheuvel 2016-12-08 65 int err;
80966672 Ard Biesheuvel 2016-12-08 66
80966672 Ard Biesheuvel 2016-12-08 67 if (nbytes <= CHACHA20_BLOCK_SIZE || !may_use_simd())
80966672 Ard Biesheuvel 2016-12-08 @68 return crypto_chacha20_crypt(desc, dst, src, nbytes);
80966672 Ard Biesheuvel 2016-12-08 69
80966672 Ard Biesheuvel 2016-12-08 70 blkcipher_walk_init(&walk, dst, src, nbytes);
80966672 Ard Biesheuvel 2016-12-08 71 err = blkcipher_walk_virt_block(desc, &walk, CHACHA20_BLOCK_SIZE);
80966672 Ard Biesheuvel 2016-12-08 72
80966672 Ard Biesheuvel 2016-12-08 73 crypto_chacha20_init(state, crypto_blkcipher_ctx(desc->tfm), walk.iv);
80966672 Ard Biesheuvel 2016-12-08 74
80966672 Ard Biesheuvel 2016-12-08 75 kernel_neon_begin();
80966672 Ard Biesheuvel 2016-12-08 76
80966672 Ard Biesheuvel 2016-12-08 77 while (walk.nbytes >= CHACHA20_BLOCK_SIZE) {
80966672 Ard Biesheuvel 2016-12-08 78 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr,
80966672 Ard Biesheuvel 2016-12-08 79 rounddown(walk.nbytes, CHACHA20_BLOCK_SIZE));
80966672 Ard Biesheuvel 2016-12-08 80 err = blkcipher_walk_done(desc, &walk,
80966672 Ard Biesheuvel 2016-12-08 81 walk.nbytes % CHACHA20_BLOCK_SIZE);
80966672 Ard Biesheuvel 2016-12-08 82 }
80966672 Ard Biesheuvel 2016-12-08 83
80966672 Ard Biesheuvel 2016-12-08 84 if (walk.nbytes) {
80966672 Ard Biesheuvel 2016-12-08 85 chacha20_dosimd(state, walk.dst.virt.addr, walk.src.virt.addr,
80966672 Ard Biesheuvel 2016-12-08 86 walk.nbytes);
80966672 Ard Biesheuvel 2016-12-08 87 err = blkcipher_walk_done(desc, &walk, 0);
80966672 Ard Biesheuvel 2016-12-08 88 }
80966672 Ard Biesheuvel 2016-12-08 89
80966672 Ard Biesheuvel 2016-12-08 90 kernel_neon_end();
80966672 Ard Biesheuvel 2016-12-08 91
80966672 Ard Biesheuvel 2016-12-08 92 return err;
80966672 Ard Biesheuvel 2016-12-08 93 }
80966672 Ard Biesheuvel 2016-12-08 94
80966672 Ard Biesheuvel 2016-12-08 95 static struct crypto_alg alg = {
80966672 Ard Biesheuvel 2016-12-08 96 .cra_name = "chacha20",
80966672 Ard Biesheuvel 2016-12-08 97 .cra_driver_name = "chacha20-neon",
80966672 Ard Biesheuvel 2016-12-08 98 .cra_priority = 300,
80966672 Ard Biesheuvel 2016-12-08 99 .cra_flags = CRYPTO_ALG_TYPE_BLKCIPHER,
80966672 Ard Biesheuvel 2016-12-08 100 .cra_blocksize = 1,
80966672 Ard Biesheuvel 2016-12-08 101 .cra_type = &crypto_blkcipher_type,
80966672 Ard Biesheuvel 2016-12-08 102 .cra_ctxsize = sizeof(struct chacha20_ctx),
80966672 Ard Biesheuvel 2016-12-08 103 .cra_alignmask = sizeof(u32) - 1,
80966672 Ard Biesheuvel 2016-12-08 104 .cra_module = THIS_MODULE,
80966672 Ard Biesheuvel 2016-12-08 105 .cra_u = {
80966672 Ard Biesheuvel 2016-12-08 106 .blkcipher = {
80966672 Ard Biesheuvel 2016-12-08 107 .min_keysize = CHACHA20_KEY_SIZE,
80966672 Ard Biesheuvel 2016-12-08 108 .max_keysize = CHACHA20_KEY_SIZE,
80966672 Ard Biesheuvel 2016-12-08 109 .ivsize = CHACHA20_IV_SIZE,
80966672 Ard Biesheuvel 2016-12-08 110 .geniv = "seqiv",
80966672 Ard Biesheuvel 2016-12-08 @111 .setkey = crypto_chacha20_setkey,
80966672 Ard Biesheuvel 2016-12-08 112 .encrypt = chacha20_simd,
80966672 Ard Biesheuvel 2016-12-08 113 .decrypt = chacha20_simd,
80966672 Ard Biesheuvel 2016-12-08 114 },
:::::: The code at line 68 was first introduced by commit
:::::: 8096667273477e735b0072b11a6d617ccee45e5f crypto: arm/chacha20 - implement NEON version based on SSE3 code
:::::: TO: Ard Biesheuvel <ard.biesheuvel@linaro.org>
:::::: CC: Herbert Xu <herbert@gondor.apana.org.au>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 60341 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
From: Challa, Mahipal @ 2016-12-27 11:39 UTC (permalink / raw)
To: Herbert Xu, Jan Glauber
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
David S . Miller, Nair, Vishnu
In-Reply-To: <20161227090227.GC10121@gondor.apana.org.au>
Hi Herbert,
Thanks for your response
>Hi Jan:
On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote:
> >
> >this series adds support for hardware accelerated compression & decompression
> >as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally
> >for some time and would like to get feedback on the RFC to see if this goes
> >into the right direction and to see if there are any concerns.
> >
> >We've discussed switching to the new acomp algorithm but for the time being
> >decided against acomp because our test cases are not yet supported with it.
> OK. Do you see any major problems in converting this over to acomp?
Mahipal: One major issue is, the kernel use cases to validate the Cavium ThunderX ZIP driver are "ZSWAP" and "IPComp" which are not yet supported with scomp-acomp framework.
Regards,
-Mahipal
From: Herbert Xu <herbert@gondor.apana.org.au>
Sent: Tuesday, December 27, 2016 2:32 PM
To: Jan Glauber
Cc: linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org; David S . Miller; Challa, Mahipal; Nair, Vishnu
Subject: Re: [RFC PATCH 0/3] Cavium ThunderX ZIP driver
Hi Jan:
On Mon, Dec 12, 2016 at 04:04:36PM +0100, Jan Glauber wrote:
>
> this series adds support for hardware accelerated compression & decompression
> as found on ThunderX (arm64) SOCs. I've been reviewing this driver internally
> for some time and would like to get feedback on the RFC to see if this goes
> into the right direction and to see if there are any concerns.
>
> We've discussed switching to the new acomp algorithm but for the time being
> decided against acomp because our test cases are not yet supported with it.
OK. Do you see any major problems in converting this over to acomp?
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: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash
From: Daniel Borkmann @ 2016-12-27 14:16 UTC (permalink / raw)
To: Herbert Xu, Andy Lutomirski
Cc: Ard Biesheuvel, Andy Lutomirski, Netdev, LKML,
Linux Crypto Mailing List, Jason A. Donenfeld,
Hannes Frederic Sowa, Alexei Starovoitov, Eric Dumazet,
Eric Biggers, Tom Herbert, David S. Miller
In-Reply-To: <20161227095853.GA10588@gondor.apana.org.au>
On 12/27/2016 10:58 AM, Herbert Xu wrote:
> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>>
>> According to Daniel, the networking folks want to let embedded systems
>> include BPF without requiring the crypto core.
>
> Last I checked the IPv4 stack depended on the crypto API so this
> sounds bogus.
I think there's a bit of a mixup here with what I said. To clarify,
requirement back then from tracing folks was that bpf engine and
therefore bpf syscall can be build w/o networking enabled for small
devices, so dependencies preferably need to be kept on a absolute
minimum, same counts for either making it suddenly a depend on
CRYPTO or a select CRYPTO for just those few lines that can be
pulled in from lib/ code instead.
^ permalink raw reply
* Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Ard Biesheuvel @ 2016-12-27 14:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, linux-arm-kernel
In-Reply-To: <20161227100400.GA10629@gondor.apana.org.au>
> On 27 Dec 2016, at 10:04, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Thu, Dec 08, 2016 at 02:28:57PM +0000, Ard Biesheuvel wrote:
>> Another port of existing x86 SSE code to NEON, again both for arm64 and ARM.
>>
>> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be
>> an efficient software implementable 'standby cipher', in case AES cannot
>> be used.
>>
>> This NEON implementation is almost 2x as fast as the generic C code
>> (measured on Cortex-A57 using the arm64 version)
>>
>> I'm aware that blkciphers are deprecated in favor of skciphers, but this
>> code (like the x86 version) uses the init and setkey routines of the generic
>> version, so it is probably better to port all implementations at once.
>>
>> Ard Biesheuvel (2):
>> crypto: arm64/chacha20 - implement NEON version based on SSE3 code
>> crypto: arm/chacha20 - implement NEON version based on SSE3 code
>
> Both patches applied. Thanks.
You just nacked the v2 of this series (due to the chunksize/walksize) and i rewrote them as skciphers as well
> --
> 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 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Jeffrey Walton @ 2016-12-27 15:36 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1481207339-17332-1-git-send-email-ard.biesheuvel@linaro.org>
> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be
> an efficient software implementable 'standby cipher', in case AES cannot
> be used.
That's not quite correct.
The IETF changed the algorithm a bit, and its not compatible with
Bernstein's ChaCha. They probably should have differentiated the name
to avoid this sort of confusion.
You can find Bernstein's specification for ChaCha at
https://cr.yp.to/chacha.html, and the test vectors for Bernstein's
specification at
http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors.
Jeff
^ permalink raw reply
* Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-27 18:35 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161227085745.GA10121@gondor.apana.org.au>
On 27 December 2016 at 08:57, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Fri, Dec 09, 2016 at 01:47:26PM +0000, Ard Biesheuvel wrote:
>> The bit-sliced NEON implementation of AES only performs optimally if
>> it can process 8 blocks of input in parallel. This is due to the nature
>> of bit slicing, where the n-th bit of each byte of AES state of each input
>> block is collected into NEON register 'n', for registers q0 - q7.
>>
>> This implies that the amount of work for the transform is fixed,
>> regardless of whether we are handling just one block or 8 in parallel.
>>
>> So let's try a bit harder to iterate over the input in suitably sized
>> chunks, by increasing the chunksize to 8 * AES_BLOCK_SIZE, and tweaking
>> the loops to only process multiples of the chunk size, unless we are
>> handling the last chunk in the input stream.
>>
>> Note that the skcipher walk API guarantees that a step in the walk never
>> returns less that 'chunksize' bytes if there are at least that many bytes
>> of input still available. However, it does *not* guarantee that those steps
>> produce an exact multiple of the chunk size.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> I like this patch. However, I had different plans for the chunksize
> attribute. It's primarily meant to be a hint to the upper layer
> in case it does partial updates. It's meant to provide the minimum
> number of bytes a partial update can carry without screwing up
> subsequent updates.
>
> It just happens to be the same value that we were using during
> an skcipher walk.
>
> So I think for your case we should add a new attribute, perhaps
> walk_chunksize or walksize, which doesn't need to be exported to
> the outside at all and can then be used by the walk interface.
>
OK, I will try to hack something up.
One thing to keep in mind though is that stacked chaining modes should
present the data with the same granularity for optimal performance.
E.g., xts(ecb(aes)) should pass 8 blocks at a time. How should this
requirement be incorporated according to you?
^ permalink raw reply
* Re: [RFC PATCH 4.10 1/6] crypto/sha256: Refactor the API so it can be used without shash
From: Andy Lutomirski @ 2016-12-27 19:00 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Herbert Xu, Ard Biesheuvel, Andy Lutomirski, Netdev, LKML,
Linux Crypto Mailing List, Jason A. Donenfeld,
Hannes Frederic Sowa, Alexei Starovoitov, Eric Dumazet,
Eric Biggers, Tom Herbert, David S. Miller
In-Reply-To: <586277AE.80401@iogearbox.net>
On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 12/27/2016 10:58 AM, Herbert Xu wrote:
>>
>> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>>>
>>>
>>> According to Daniel, the networking folks want to let embedded systems
>>> include BPF without requiring the crypto core.
>>
>>
>> Last I checked the IPv4 stack depended on the crypto API so this
>> sounds bogus.
>
>
> I think there's a bit of a mixup here with what I said. To clarify,
> requirement back then from tracing folks was that bpf engine and
> therefore bpf syscall can be build w/o networking enabled for small
> devices, so dependencies preferably need to be kept on a absolute
> minimum, same counts for either making it suddenly a depend on
> CRYPTO or a select CRYPTO for just those few lines that can be
> pulled in from lib/ code instead.
Somehow I had that in my head as "networking" not "tracing", probably
because of the TCA stuff. Whoops.
Anyway, I'm rewriting the crypto part of the patch completely based on
Ard's feedback.
^ permalink raw reply
* Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20
From: Ard Biesheuvel @ 2016-12-27 19:17 UTC (permalink / raw)
To: noloader; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <CAH8yC8kJiKc4Oz8RAob_5oRoQeACqvqXyj2UAsfv4bQ_TmKG-w@mail.gmail.com>
On 27 December 2016 at 15:36, Jeffrey Walton <noloader@gmail.com> wrote:
>> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be
>> an efficient software implementable 'standby cipher', in case AES cannot
>> be used.
>
> That's not quite correct.
>
> The IETF changed the algorithm a bit, and its not compatible with
> Bernstein's ChaCha. They probably should have differentiated the name
> to avoid this sort of confusion.
>
> You can find Bernstein's specification for ChaCha at
> https://cr.yp.to/chacha.html, and the test vectors for Bernstein's
> specification at
> http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors.
>
Thanks for the clarification. However, this should not affect the
content of the patches: they simply reimplement in ARM SIMD what the
kernel already knows as "chacha20", which is the IETF derivative
rather than djb's original. I will mention this in the cover letter of
the next respin (given that I need to respin these anyway)
^ permalink raw reply
* [PATCH 1/8] random: remove stale maybe_reseed_primary_crng
From: Stephan Müller @ 2016-12-27 22:39 UTC (permalink / raw)
To: Ted Tso; +Cc: linux-kernel, linux-crypto
In-Reply-To: <3254875.f5A5oHPdxF@positron.chronox.de>
>From 5e84a71d4c4b3c7f015878c0907102634603d270 Mon Sep 17 00:00:00 2001
From: Stephan Mueller <stephan.mueller@atsec.com>
Date: Thu, 15 Dec 2016 12:42:33 +0100
Subject:
The function maybe_reseed_primary_crng is not used anywhere and thus can
be removed. Besides, it contains the check crng_init > 2 which will
never become true and thus would never trigger a reseed of the ChaCha20
primary DRNG.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
drivers/char/random.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 1ef2640..8e5ab20 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -855,13 +855,6 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
spin_unlock_irqrestore(&primary_crng.lock, flags);
}
-static inline void maybe_reseed_primary_crng(void)
-{
- if (crng_init > 2 &&
- time_after(jiffies, primary_crng.init_time + CRNG_RESEED_INTERVAL))
- crng_reseed(&primary_crng, &input_pool);
-}
-
static inline void crng_wait_ready(void)
{
wait_event_interruptible(crng_init_wait, crng_ready());
--
2.9.3
^ 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