Re: [PATCH] crypto: talitos: fix driver init

On Thu, 28 Apr 2016 17:15:30 +0300 Alexandru Ardelean wrote: > From: Alexandru Ardelean > > Crypto hash algorithms must provide the statesize sometime > from kernel 4.2 onwards. > Since commit 8996eafdcbad149ac0f772fb1649fbb75c482a6a > >

Re: random(4) changes

> I think we can agree that we disagree. Yes, we agree on that, at least! The problem is, this is supposed to be a matter of fact, not opinion, so there should be one right answer. I suppose it's possible it's still an issue of terminology, but we've exhausted > Though, I will get back to the

Re: random(4) changes

Am Freitag, 29. April 2016, 16:08:48 schrieb George Spelvin: Hi George, > > What I am saying that the bits in one given time stamp are mutually > > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that > > very same time stamp. > > And I'm saying that's wrong. I think we

Re: [PATCH 4/5] crypto: Use dma_pool_zalloc

On Fri, 29 Apr 2016 22:09:11 +0200 Julia Lawall wrote: > Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch > that makes this transformation is as follows: (http://coccinelle.lip6.fr/) > > // > @@ > expression d,e; > statement S; > @@ > > d

[PATCH 0/5] Use dma_pool_zalloc

Dma_pool_zalloc combines dma_pool_alloc and memset 0. The semantic patch that makes this transformation is as follows: (http://coccinelle.lip6.fr/) // @@ type T; T *d; expression e; statement S; @@ d = -dma_pool_alloc +dma_pool_zalloc (...);

Re: random(4) changes

> What I am saying that the bits in one given time stamp are mutually > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that > very same time stamp. And I'm saying that's wrong. We are interested in the correlation from the point of view of someone who knows all previous

Re: random(4) changes

Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin: Hi George, > >> 1. It DOES depend on the attacker. Any statement about independence > >> > >>depends on the available knowledge. > >> > >> 2. XOR being entropy preserving depends on independence ONLY, it does > >> > >>NOT

[PATCH 1/2] crypto: qat - Fix typo in comments

Fix copy and paste typo adf_isr.c Signed-off-by: Tadeusz Struk --- drivers/crypto/qat/qat_common/adf_isr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/qat/qat_common/adf_isr.c b/drivers/crypto/qat/qat_common/adf_isr.c index

[PATCH 2/2] crypto: qat - make adf_vf_isr.c dependant on IOV config

The adf_vf_isr.c should only be build if CONFIG_PCI_IOV is enabled Signed-off-by: Tadeusz Struk --- drivers/crypto/qat/qat_common/Makefile | 4 ++-- drivers/crypto/qat/qat_common/adf_common_drv.h | 14 -- 2 files changed, 14 insertions(+), 4

[PATCH] crypto: qat - fix adf_ctl_drv.c:undefined reference to adf_init_pf_wq

Fix undefined reference issue reported by kbuild test robot. Reported-by: kbuild test robot Signed-off-by: Tadeusz Struk --- drivers/crypto/qat/qat_common/adf_common_drv.h | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-)

[PATCH] lib: asn1_decoder - add MODULE_LICENSE("GPL")

A kernel taint results when loading the rsa_generic module: root@(none):~# modprobe rsa_generic asn1_decoder: module license 'unspecified' taints kernel. Disabling lock debugging due to kernel taint "Tainting" of the kernel is (usually) a way of indicating that a proprietary module has been

[PATCH] crypto: vmx - comply with ABIs that specify vrsave as reserved.

It gives significant improvements ( ~+15%) on some modes. These code has been adopted from OpenSSL project in collaboration with the original author (Andy Polyakov ). --- drivers/crypto/vmx/ppc-xlate.pl | 20 1 file changed, 20 insertions(+) diff --git

[PATCH v4 2/3] crypto: scatterwalk - export scatterwalk_pagedone

Used in caam driver. Export the symbol since the caam driver can be built as a module. Signed-off-by: Tudor Ambarus --- crypto/scatterwalk.c | 5 +++-- include/crypto/scatterwalk.h | 2 ++ 2 files changed, 5 insertions(+), 2 deletions(-) diff --git

[PATCH v4 3/3] crypto: caam - add support for RSA algorithm

Add RSA support to caam driver. Coauthored-by: Yashpal Dutta Signed-off-by: Tudor Ambarus --- drivers/crypto/caam/Kconfig| 12 ++ drivers/crypto/caam/Makefile | 4 + drivers/crypto/caam/caampkc.c | 470

[PATCH v4 0/3] crypto: caam - add support for RSA algorithm

Depends on: http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg18724.html v3 parch set can be found here: http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg18429.html Changes to v3 patch set: - "crypto: caam - add support for RSA algorithm" - update the driver to use

[PATCH v4 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks

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

[PATCH] crypto: omap-des: Use dma_request_chan() for requesting DMA channel

With the new dma_request_chan() the client driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the driver can now support deferred probing against DMA. Signed-off-by: Peter Ujfalusi CC: Herbert Xu

[PATCH] crypto: omap-sham: Use dma_request_chan() for requesting DMA channel

With the new dma_request_chan() the client driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the driver can now support deferred probing against DMA. Signed-off-by: Peter Ujfalusi CC: Herbert Xu

[PATCH] crypto: omap-aes: Use dma_request_chan() for requesting DMA channel

With the new dma_request_chan() the client driver does not need to look for the DMA resource and it does not need to pass filter_fn anymore. By switching to the new API the driver can now support deferred probing against DMA. Signed-off-by: Peter Ujfalusi CC: Herbert Xu

[PATCH] crypto: rsa - return raw integer for the ASN.1 parser

Return the raw integer with no other processing. The scope is to have only one ANS.1 parser for the RSA keys. Update the RSA software implementation so that it does the MPI conversion on top. Signed-off-by: Tudor Ambarus --- crypto/rsa.c | 122

Re: random(4) changes

Am Freitag, 29. April 2016, 07:04:24 schrieb George Spelvin: Hi George, > > I think there is a slight mixup: IID is not related to an attacker > > predicting things. IID is simply a statistical measure, it is either there > > or not. It does not depend on an attacker (assuming that the attacker

Re: [PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

On Fri, Apr 29, 2016 at 12:59:57PM +0200, Stephan Mueller wrote: > Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones: > > Hi Richard, [...] > > + if (notests) { > > What about if (!fips_enabled && notests) ? > > I am not sure whether the kernel should prevent mistakes in user

Re: random(4) changes

> I think there is a slight mixup: IID is not related to an attacker > predicting things. IID is simply a statistical measure, it is either there > or not. It does not depend on an attacker (assuming that the attacker > cannot change the data). Note, the IID is only needed to claim that the > XOR

[PATCH v2] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. Signed-off-by: Richard W.M. Jones --- Documentation/kernel-parameters.txt | 3 +++ crypto/testmgr.c| 9

[PATCH v2] crypto: Add a flag allowing the self-tests to be disabled at runtime.

v1 -> v2: - Use printk_once. Because the serial console is so slow, printing the message multiple times consumed about 6ms extra later on in the boot. Printing it only once is both neater and avoids this extra overhead. Rich. - - - I'm trying to reduce the time taken in the kernel in

Re: [PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones: Hi Richard, > Running self-tests for a short-lived KVM VM takes 28ms on my laptop. > This commit adds a flag 'cryptomgr.notests' which allows them to be > disabled. > > Signed-off-by: Richard W.M. Jones > --- >

[PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

I'm trying to reduce the time taken in the kernel in initcalls, with my aim being to reduce the current ~700ms spent in initcalls before userspace, down to something like 100ms. All times on my Broadwell-U laptop, under virtualization. The purpose of this is to be able to launch VMs around

[PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Running self-tests for a short-lived KVM VM takes 28ms on my laptop. This commit adds a flag 'cryptomgr.notests' which allows them to be disabled. Signed-off-by: Richard W.M. Jones --- Documentation/kernel-parameters.txt | 3 +++ crypto/testmgr.c| 9

Re: random(4) changes

Am Freitag, 29. April 2016, 05:34:18 schrieb George Spelvin: Hi George, > (Note that we have two chains of e-mails crossing mid-stream. I'm in > the middle of working on a much longer reply to your previous e-mail.) > > >> They're not independent, nor are they identically distributed. > > > >

Re: random(4) changes

(Note that we have two chains of e-mails crossing mid-stream. I'm in the middle of working on a much longer reply to your previous e-mail.) >> They're not independent, nor are they identically distributed. > That is an interesting statement: you say that the time stamp has holes > in it, i.e.

Re: random(4) changes

Am Freitag, 29. April 2016, 03:29:50 schrieb George Spelvin: Hi George, > > 1. the individual bits of a given 32 bit time stamp are independent > > > >(or IID in terms of NIST) > > They're not independent, nor are they identically distributed. That is an interesting statement: you say

Re: random(4) changes

>From smuel...@chronox.de Fri Apr 29 04:56:49 2016 From: Stephan Mueller To: George Spelvin Cc: herb...@gondor.apana.org.au, linux-crypto@vger.kernel.org, linux-ker...@vger.kernel.org, sandyinch...@gmail.com, ty...@mit.edu Subject: Re: random(4) changes

[PATCH v3 5/5] random: add interrupt callback to VMBus IRQ handler

The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy collector is not triggered. This patch adds

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

>From 443dd61dcf2cf5a7a516c552da463ee2d8aea949 Mon Sep 17 00:00:00 2001 From: Stephan Mueller Date: Mon, 18 Apr 2016 10:04:33 +0200 Subject: This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by: Stephan

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

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

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

Hi Herbert, Ted, Andi, 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

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

Add LRNG compilation support. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 ++ crypto/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 93a1fdc..938f2dc 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig

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

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.