* Re: [PATCH] crypto: x86/glue_helper make bool
From: Paul Gortmaker @ 2016-07-21 23:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: herbert, davem, lkp, linux-crypto, linux-kernel
In-Reply-To: <1469139180-26863-1-git-send-email-mcgrof@kernel.org>
[[PATCH] crypto: x86/glue_helper make bool] On 21/07/2016 (Thu 15:13) Luis R. Rodriguez wrote:
> Paul's changes to remove MODULE_LICENSE() out of the x86 glue_helper
> causes a kernel with CONFIG_CRYPTO_GLUE_HELPER_X86=m to taint since
> it now detects the license is missing if you try to build the driver
> as a module, log below.
Reported and fixed two days ago ; the fix went out in yesterday's
linux-next via the tip tree.
https://lkml.kernel.org/r/20160719144243.GK21225@windriver.com
I fixed it by restoring the license, since making it bool might break
existing use cases, and my intent of this audit was to get rid of stuff
without altering runtime at all.
Thanks,
Paul.
--
>
> Fix this by removing the module option for it via Kconfig as it
> cannot be a module.
>
> glue_helper: module license 'unspecified' taints kernel.
> glue_helper: module license 'unspecified' taints kernel.
> Disabling lock debugging due to kernel taint
> glue_helper: Unknown symbol blkcipher_walk_done (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt (err 0)
> glue_helper: Unknown symbol kernel_fpu_end (err 0)
> glue_helper: Unknown symbol kernel_fpu_begin (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt_block (err 0)
> glue_helper: Unknown symbol blkcipher_walk_done (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt (err 0)
> glue_helper: Unknown symbol kernel_fpu_end (err 0)
> glue_helper: Unknown symbol kernel_fpu_begin (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt_block (err 0)
> glue_helper: Unknown symbol blkcipher_walk_done (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt (err 0)
> glue_helper: Unknown symbol kernel_fpu_end (err 0)
> glue_helper: Unknown symbol kernel_fpu_begin (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt_block (err 0)
> glue_helper: Unknown symbol blkcipher_walk_done (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt (err 0)
> glue_helper: Unknown symbol kernel_fpu_end (err 0)
> glue_helper: Unknown symbol kernel_fpu_begin (err 0)
> glue_helper: Unknown symbol blkcipher_walk_virt_block (err 0)
>
> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
> ---
> crypto/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index a9377bef25e3..ed6abf4bbf3b 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -237,7 +237,7 @@ config CRYPTO_ABLK_HELPER
> select CRYPTO_CRYPTD
>
> config CRYPTO_GLUE_HELPER_X86
> - tristate
> + bool
> depends on X86
> select CRYPTO_ALGAPI
>
> --
> 2.8.4
>
^ permalink raw reply
* Re: [PATCH] crypto: x86/glue_helper make bool
From: Luis R. Rodriguez @ 2016-07-21 23:06 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Luis R. Rodriguez, herbert, davem, lkp, linux-crypto,
linux-kernel
In-Reply-To: <20160721230111.GI21225@windriver.com>
On Thu, Jul 21, 2016 at 07:01:11PM -0400, Paul Gortmaker wrote:
> [[PATCH] crypto: x86/glue_helper make bool] On 21/07/2016 (Thu 15:13) Luis R. Rodriguez wrote:
>
> > Paul's changes to remove MODULE_LICENSE() out of the x86 glue_helper
> > causes a kernel with CONFIG_CRYPTO_GLUE_HELPER_X86=m to taint since
> > it now detects the license is missing if you try to build the driver
> > as a module, log below.
>
> Reported and fixed two days ago ; the fix went out in yesterday's
> linux-next via the tip tree.
>
> https://lkml.kernel.org/r/20160719144243.GK21225@windriver.com
>
> I fixed it by restoring the license, since making it bool might break
> existing use cases,
How so?
Luis
^ permalink raw reply
* Re: [PATCH] crypto: x86/glue_helper make bool
From: Paul Gortmaker @ 2016-07-21 23:13 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: herbert, davem, lkp, linux-crypto, linux-kernel
In-Reply-To: <20160721230607.GA5537@wotan.suse.de>
[Re: [PATCH] crypto: x86/glue_helper make bool] On 22/07/2016 (Fri 01:06) Luis R. Rodriguez wrote:
> On Thu, Jul 21, 2016 at 07:01:11PM -0400, Paul Gortmaker wrote:
> > [[PATCH] crypto: x86/glue_helper make bool] On 21/07/2016 (Thu 15:13) Luis R. Rodriguez wrote:
> >
> > > Paul's changes to remove MODULE_LICENSE() out of the x86 glue_helper
> > > causes a kernel with CONFIG_CRYPTO_GLUE_HELPER_X86=m to taint since
> > > it now detects the license is missing if you try to build the driver
> > > as a module, log below.
> >
> > Reported and fixed two days ago ; the fix went out in yesterday's
> > linux-next via the tip tree.
> >
> > https://lkml.kernel.org/r/20160719144243.GK21225@windriver.com
> >
> > I fixed it by restoring the license, since making it bool might break
> > existing use cases,
>
> How so?
In the now deleted text, you wrote:
Fix this by removing the module option for it via Kconfig as it
cannot be a module.
glue_helper: module license 'unspecified' taints kernel.
The 2nd line of output clearly contradicts your 1st line stating it
cannot be a module. It clearly was a module, and loaded, and tainted
the kernel because it had no license.
As for use cases, there can be many that could break. Someone with a
kernel that just fit in flash, now ends up with glue_helper builtin, and
their kernel won't fit anymore.
Or someone has a script that manually ran "modprobe glue_helper" at
startup along with other specifically chosen modules. Now that step
will fail.
As I said, I don't want to be introducing runtime changes in an audit
for unnecessary module.h instances.
Paul.
--
>
> Luis
^ permalink raw reply
* Crypto Fixes for 4.7
From: Herbert Xu @ 2016-07-22 3:39 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160520084105.GA3959@gondor.apana.org.au>
Hi Linus:
This push fixes a sporadic build failure in the qat driver.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Jan Stancek (1):
crypto: qat - make qat_asym_algs.o depend on asn1 headers
drivers/crypto/qat/qat_common/Makefile | 1 +
1 file changed, 1 insertion(+)
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: Max data limit for AEAD operation
From: Herbert Xu @ 2016-07-22 4:40 UTC (permalink / raw)
To: Harsh Jain; +Cc: linux-crypto
In-Reply-To: <CAFXBA==j+6fGuWrjNroGWnnBc13ev+6EB2Ae7SnwAVVxjTWBrw@mail.gmail.com>
Harsh Jain <harshjain.prof@gmail.com> wrote:
>
> There is maximum limit of data which crypto user can send(in encrypt)
> to get TAG in AEAD operations. We do not have update/final like
> implementation for AEAD algo's. why is this so?
Because our users haven't needed it so far. Also algorithms like CCM
cannot support such an operation.
If you have a valid use case for it then I'll consider it.
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: Max data limit for AEAD operation
From: Harsh Jain @ 2016-07-22 4:45 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20160722044019.GA17416@gondor.apana.org.au>
Hi,
Thank for reply. As such I don't have any use case. But the use case I
can think of is AEAD operation on large file using AF_ALG interface.
If user tried this he/she will get invalid TAG value.
Regards
Harsh Jain
On Fri, Jul 22, 2016 at 10:10 AM, Herbert Xu
<herbert@gondor.apana.org.au> wrote:
> Harsh Jain <harshjain.prof@gmail.com> wrote:
>>
>> There is maximum limit of data which crypto user can send(in encrypt)
>> to get TAG in AEAD operations. We do not have update/final like
>> implementation for AEAD algo's. why is this so?
>
> Because our users haven't needed it so far. Also algorithms like CCM
> cannot support such an operation.
>
> If you have a valid use case for it then I'll consider it.
>
> 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: [V2,1/2] powerpc: Add module autoloading based on CPU features
From: Michael Ellerman @ 2016-07-22 5:50 UTC (permalink / raw)
To: Alastair D'Silva
Cc: herbert, linux-kernel, paulus, linux-crypto, Alastair D'Silva,
linuxppc-dev, davem
In-Reply-To: <1468901033-28996-2-git-send-email-alastair@au1.ibm.com>
On Tue, 2016-19-07 at 04:03:52 UTC, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> This patch provides the necessary infrastructure to allow drivers
> to be automatically loaded via UDEV. It implements the minimum
> required to be able to use module_cpu_feature_match to trigger
> the GENERIC_CPU_AUTOPROBE mechanisms.
>
> The features exposed are a mirror of the cpu_user_features
> (converted to an offset from a mask). This decision was made to
> ensure that the behavior between features for module loading and
> userspace are consistent.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4a1202765ddf4e5bb3143c0a85
cheers
^ permalink raw reply
* Re: [V2, 2/2] crypto: vmx - Convert to CPU feature based module autoloading
From: Michael Ellerman @ 2016-07-22 5:50 UTC (permalink / raw)
To: Alastair D'Silva
Cc: herbert, linux-kernel, paulus, linux-crypto, Alastair D'Silva,
linuxppc-dev, davem
In-Reply-To: <1468901033-28996-3-git-send-email-alastair@au1.ibm.com>
On Tue, 2016-19-07 at 04:03:53 UTC, Alastair D'Silva wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
> to automatically load the vmx_crypto module if the CPU supports
> it.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ccf5c442a1b82bf74105d72416
cheers
^ permalink raw reply
* [PATCH] crypto: marvell - Fix memory leaks in TDMA chain for cipher requests
From: Romain Perier @ 2016-07-22 12:40 UTC (permalink / raw)
To: Boris Brezillon, Arnaud Ebalard
Cc: David S. Miller, linux-crypto, Thomas Petazzoni, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
So far in mv_cesa_ablkcipher_dma_req_init, if an error is thrown while
the tdma chain is built there is a memory leak. This issue exists
because the chain is assigned later at the end of the function, so the
cleanup function is called with the wrong version of the chain.
Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support")
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/crypto/marvell/cipher.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
index 48df03a..8391aba 100644
--- a/drivers/crypto/marvell/cipher.c
+++ b/drivers/crypto/marvell/cipher.c
@@ -320,7 +320,6 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
GFP_KERNEL : GFP_ATOMIC;
struct mv_cesa_req *basereq = &creq->base;
struct mv_cesa_ablkcipher_dma_iter iter;
- struct mv_cesa_tdma_chain chain;
bool skip_ctx = false;
int ret;
unsigned int ivsize;
@@ -347,13 +346,13 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
return -ENOMEM;
}
- mv_cesa_tdma_desc_iter_init(&chain);
+ mv_cesa_tdma_desc_iter_init(&basereq->chain);
mv_cesa_ablkcipher_req_iter_init(&iter, req);
do {
struct mv_cesa_op_ctx *op;
- op = mv_cesa_dma_add_op(&chain, op_templ, skip_ctx, flags);
+ op = mv_cesa_dma_add_op(&basereq->chain, op_templ, skip_ctx, flags);
if (IS_ERR(op)) {
ret = PTR_ERR(op);
goto err_free_tdma;
@@ -363,18 +362,18 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
mv_cesa_set_crypt_op_len(op, iter.base.op_len);
/* Add input transfers */
- ret = mv_cesa_dma_add_op_transfers(&chain, &iter.base,
+ ret = mv_cesa_dma_add_op_transfers(&basereq->chain, &iter.base,
&iter.src, flags);
if (ret)
goto err_free_tdma;
/* Add dummy desc to launch the crypto operation */
- ret = mv_cesa_dma_add_dummy_launch(&chain, flags);
+ ret = mv_cesa_dma_add_dummy_launch(&basereq->chain, flags);
if (ret)
goto err_free_tdma;
/* Add output transfers */
- ret = mv_cesa_dma_add_op_transfers(&chain, &iter.base,
+ ret = mv_cesa_dma_add_op_transfers(&basereq->chain, &iter.base,
&iter.dst, flags);
if (ret)
goto err_free_tdma;
@@ -383,13 +382,12 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
/* Add output data for IV */
ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(req));
- ret = mv_cesa_dma_add_iv_op(&chain, CESA_SA_CRYPT_IV_SRAM_OFFSET,
+ ret = mv_cesa_dma_add_iv_op(&basereq->chain, CESA_SA_CRYPT_IV_SRAM_OFFSET,
ivsize, CESA_TDMA_SRC_IN_SRAM, flags);
if (ret)
goto err_free_tdma;
- basereq->chain = chain;
basereq->chain.last->flags |= CESA_TDMA_END_OF_REQ;
return 0;
--
2.8.1
^ permalink raw reply related
* [PATCH] crypto: marvell - Don't chain at DMA level when backlog is disabled
From: Romain Perier @ 2016-07-22 12:40 UTC (permalink / raw)
To: Boris Brezillon, Arnaud Ebalard
Cc: David S. Miller, linux-crypto, Thomas Petazzoni, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
The flag CRYPTO_TFM_REQ_MAY_BACKLOG is optional and can be set from the
user to put requests into the backlog queue when the main cryptographic
queue is full. Before calling mv_cesa_tdma_chain we must check the value
of the return status to be sure that the current request has been
correctly queued or added to the backlog.
Fixes: 85030c5168f1 ("crypto: marvell - Add support for chaining...")
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/crypto/marvell/cesa.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index e373cc6..d64af86 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -180,10 +180,11 @@ int mv_cesa_queue_req(struct crypto_async_request *req,
struct mv_cesa_engine *engine = creq->engine;
spin_lock_bh(&engine->lock);
- if (mv_cesa_req_get_type(creq) == CESA_DMA_REQ)
- mv_cesa_tdma_chain(engine, creq);
-
ret = crypto_enqueue_request(&engine->queue, req);
+ if ((mv_cesa_req_get_type(creq) == CESA_DMA_REQ) &&
+ (ret == -EINPROGRESS ||
+ (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
+ mv_cesa_tdma_chain(engine, creq);
spin_unlock_bh(&engine->lock);
if (ret != -EINPROGRESS)
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] crypto: marvell - Fix memory leaks in TDMA chain for cipher requests
From: Boris Brezillon @ 2016-07-22 13:21 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, David S. Miller, linux-crypto, Thomas Petazzoni,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <1469191239-17296-1-git-send-email-romain.perier@free-electrons.com>
On Fri, 22 Jul 2016 14:40:39 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> So far in mv_cesa_ablkcipher_dma_req_init, if an error is thrown while
> the tdma chain is built there is a memory leak. This issue exists
> because the chain is assigned later at the end of the function, so the
> cleanup function is called with the wrong version of the chain.
>
> Fixes: db509a45339f ("crypto: marvell/cesa - add TDMA support")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/crypto/marvell/cipher.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index 48df03a..8391aba 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -320,7 +320,6 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
> GFP_KERNEL : GFP_ATOMIC;
> struct mv_cesa_req *basereq = &creq->base;
> struct mv_cesa_ablkcipher_dma_iter iter;
> - struct mv_cesa_tdma_chain chain;
> bool skip_ctx = false;
> int ret;
> unsigned int ivsize;
> @@ -347,13 +346,13 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
> return -ENOMEM;
> }
>
> - mv_cesa_tdma_desc_iter_init(&chain);
> + mv_cesa_tdma_desc_iter_init(&basereq->chain);
> mv_cesa_ablkcipher_req_iter_init(&iter, req);
>
> do {
> struct mv_cesa_op_ctx *op;
>
> - op = mv_cesa_dma_add_op(&chain, op_templ, skip_ctx, flags);
> + op = mv_cesa_dma_add_op(&basereq->chain, op_templ, skip_ctx, flags);
> if (IS_ERR(op)) {
> ret = PTR_ERR(op);
> goto err_free_tdma;
> @@ -363,18 +362,18 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
> mv_cesa_set_crypt_op_len(op, iter.base.op_len);
>
> /* Add input transfers */
> - ret = mv_cesa_dma_add_op_transfers(&chain, &iter.base,
> + ret = mv_cesa_dma_add_op_transfers(&basereq->chain, &iter.base,
> &iter.src, flags);
> if (ret)
> goto err_free_tdma;
>
> /* Add dummy desc to launch the crypto operation */
> - ret = mv_cesa_dma_add_dummy_launch(&chain, flags);
> + ret = mv_cesa_dma_add_dummy_launch(&basereq->chain, flags);
> if (ret)
> goto err_free_tdma;
>
> /* Add output transfers */
> - ret = mv_cesa_dma_add_op_transfers(&chain, &iter.base,
> + ret = mv_cesa_dma_add_op_transfers(&basereq->chain, &iter.base,
> &iter.dst, flags);
> if (ret)
> goto err_free_tdma;
> @@ -383,13 +382,12 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
>
> /* Add output data for IV */
> ivsize = crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(req));
> - ret = mv_cesa_dma_add_iv_op(&chain, CESA_SA_CRYPT_IV_SRAM_OFFSET,
> + ret = mv_cesa_dma_add_iv_op(&basereq->chain, CESA_SA_CRYPT_IV_SRAM_OFFSET,
> ivsize, CESA_TDMA_SRC_IN_SRAM, flags);
>
> if (ret)
> goto err_free_tdma;
>
> - basereq->chain = chain;
> basereq->chain.last->flags |= CESA_TDMA_END_OF_REQ;
>
> return 0;
^ permalink raw reply
* Re: [PATCH] crypto: marvell - Don't chain at DMA level when backlog is disabled
From: Boris Brezillon @ 2016-07-22 13:22 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, David S. Miller, linux-crypto, Thomas Petazzoni,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <1469191255-17443-1-git-send-email-romain.perier@free-electrons.com>
On Fri, 22 Jul 2016 14:40:55 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> The flag CRYPTO_TFM_REQ_MAY_BACKLOG is optional and can be set from the
> user to put requests into the backlog queue when the main cryptographic
> queue is full. Before calling mv_cesa_tdma_chain we must check the value
> of the return status to be sure that the current request has been
> correctly queued or added to the backlog.
>
> Fixes: 85030c5168f1 ("crypto: marvell - Add support for chaining...")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/crypto/marvell/cesa.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
> index e373cc6..d64af86 100644
> --- a/drivers/crypto/marvell/cesa.c
> +++ b/drivers/crypto/marvell/cesa.c
> @@ -180,10 +180,11 @@ int mv_cesa_queue_req(struct crypto_async_request *req,
> struct mv_cesa_engine *engine = creq->engine;
>
> spin_lock_bh(&engine->lock);
> - if (mv_cesa_req_get_type(creq) == CESA_DMA_REQ)
> - mv_cesa_tdma_chain(engine, creq);
> -
> ret = crypto_enqueue_request(&engine->queue, req);
> + if ((mv_cesa_req_get_type(creq) == CESA_DMA_REQ) &&
> + (ret == -EINPROGRESS ||
> + (ret == -EBUSY && req->flags & CRYPTO_TFM_REQ_MAY_BACKLOG)))
> + mv_cesa_tdma_chain(engine, creq);
> spin_unlock_bh(&engine->lock);
>
> if (ret != -EINPROGRESS)
^ permalink raw reply
* [PATCH 0/2] Fix a resource release omission in error handling code
From: Quentin Lambert @ 2016-07-22 13:32 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel; +Cc: kernel-janitors
The first patch is a style fix, the second add calls to npe_release.
The reason for me thinking that they are necessary is that every other branches
leading to an error return are calling this function.
---
drivers/crypto/ixp4xx_crypto.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
---
^ permalink raw reply
* [PATCH 2/2] crypto: ixp4xx - Add missing npe_c release in error branches
From: Quentin Lambert @ 2016-07-22 13:32 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: kernel-janitors, Quentin Lambert
In-Reply-To: <20160722133242.21916-1-lambert.quentin@gmail.com>
Most error branches following the call to npe_request contain a call to
npe_request. This patch add a call to npe_release to error branches
following the call to npe_request that do not have it.
This issue was found with Hector.
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
If I am right in thinking that these call to npe_release are missing, another
solution would be to jump to err since the rest of the code does it.
drivers/crypto/ixp4xx_crypto.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -448,7 +448,7 @@ static int init_ixp_crypto(struct device
if (!npe_running(npe_c)) {
ret = npe_load_firmware(npe_c, npe_name(npe_c), dev);
if (ret)
- return ret;
+ goto npe_release;
if (npe_recv_message(npe_c, msg, "STATUS_MSG"))
goto npe_error;
} else {
@@ -472,7 +472,8 @@ static int init_ixp_crypto(struct device
default:
printk(KERN_ERR "Firmware of %s lacks crypto support\n",
npe_name(npe_c));
- return -ENODEV;
+ ret = -ENODEV;
+ goto npe_release;
}
/* buffer_pool will also be used to sometimes store the hmac,
* so assure it is large enough
@@ -511,6 +512,7 @@ npe_error:
err:
dma_pool_destroy(ctx_pool);
dma_pool_destroy(buffer_pool);
+npe_release:
npe_release(npe_c);
return ret;
}
^ permalink raw reply
* [PATCH 1/2] crypto: ixp4xx - Fix a "simple if" coding style warning
From: Quentin Lambert @ 2016-07-22 13:32 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: kernel-janitors, Quentin Lambert
In-Reply-To: <20160722133242.21916-1-lambert.quentin@gmail.com>
Signed-off-by: Quentin Lambert <lambert.quentin@gmail.com>
---
drivers/crypto/ixp4xx_crypto.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -447,9 +447,8 @@ static int init_ixp_crypto(struct device
if (!npe_running(npe_c)) {
ret = npe_load_firmware(npe_c, npe_name(npe_c), dev);
- if (ret) {
+ if (ret)
return ret;
- }
if (npe_recv_message(npe_c, msg, "STATUS_MSG"))
goto npe_error;
} else {
^ permalink raw reply
* [PATCH] crypto: marvell - Update cache with input sg only when it is unmapped
From: Romain Perier @ 2016-07-22 13:46 UTC (permalink / raw)
To: Boris Brezillon, Arnaud Ebalard
Cc: David S. Miller, linux-crypto, Thomas Petazzoni, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
So far, the cache of the ahash requests was updated from the 'complete'
operation. This complete operation is called from mv_cesa_tdma_process
before the cleanup operation, which means that the content of req->src
can be read and copied when it is still mapped. This commit fixes the
issue by moving this cache update from mv_cesa_ahash_complete to
mv_cesa_ahash_req_cleanup, so the copy is done once the sglist is
unmapped.
Fixes: 1bf6682cb31d ("crypto: marvell - Add a complete operation for..")
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/crypto/marvell/hash.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index c35912b..82e0f4e6 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -315,12 +315,6 @@ static void mv_cesa_ahash_complete(struct crypto_async_request *req)
for (i = 0; i < digsize / 4; i++)
creq->state[i] = readl_relaxed(engine->regs + CESA_IVDIG(i));
- if (creq->cache_ptr)
- sg_pcopy_to_buffer(ahashreq->src, creq->src_nents,
- creq->cache,
- creq->cache_ptr,
- ahashreq->nbytes - creq->cache_ptr);
-
if (creq->last_req) {
/*
* Hardware's MD5 digest is in little endian format, but
@@ -365,6 +359,12 @@ static void mv_cesa_ahash_req_cleanup(struct crypto_async_request *req)
mv_cesa_ahash_last_cleanup(ahashreq);
mv_cesa_ahash_cleanup(ahashreq);
+
+ if (creq->cache_ptr)
+ sg_pcopy_to_buffer(ahashreq->src, creq->src_nents,
+ creq->cache,
+ creq->cache_ptr,
+ ahashreq->nbytes - creq->cache_ptr);
}
static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops = {
--
2.8.1
^ permalink raw reply related
* Crypto Fixes for 4.7
From: Herbert Xu @ 2016-07-23 3:10 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160722033900.GA16972@gondor.apana.org.au>
Hi Linus:
This push fixes a sporadic build failure in the qat driver as well
as a memory corruption bug in rsa-pkcs1pad.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Herbert Xu (1):
crypto: rsa-pkcs1pad - fix rsa-pkcs1pad request struct
Jan Stancek (1):
crypto: qat - make qat_asym_algs.o depend on asn1 headers
crypto/rsa-pkcs1pad.c | 4 ++--
drivers/crypto/qat/qat_common/Makefile | 1 +
2 files changed, 3 insertions(+), 2 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
* [GIT PULL] /dev/random driver changes for 4.8
From: Theodore Ts'o @ 2016-07-25 6:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-crypto
The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus
for you to fetch changes up to 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec:
random: strengthen input validation for RNDADDTOENTCNT (2016-07-03 17:09:33 -0400)
----------------------------------------------------------------
A number of improvements for the /dev/random driver; the most
important is the use of a ChaCha20-based CRNG for /dev/urandom, which
is faster, more efficient, and easier to make scalable for
silly/abusive userspace programs that want to read from /dev/urandom
in a tight loop on NUMA systems.
This set of patches also improves entropy gathering on VM's running on
Microsoft Azure, and will take advantage of a hw random number
generator (if present) to initialize the /dev/urandom pool.
----------------------------------------------------------------
Eric Biggers (1):
random: properly align get_random_int_hash
Stephan Mueller (1):
random: add interrupt callback to VMBus IRQ handler
Theodore Ts'o (6):
random: initialize the non-blocking pool via add_hwgenerator_randomness()
random: print a warning for the first ten uninitialized random users
random: replace non-blocking pool with a Chacha20-based CRNG
random: make /dev/urandom scalable for silly userspace programs
random: add backtracking protection to the CRNG
random: strengthen input validation for RNDADDTOENTCNT
crypto/chacha20_generic.c | 61 ----------
drivers/char/random.c | 482 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------
drivers/hv/vmbus_drv.c | 3 +
include/crypto/chacha20.h | 1 +
lib/Makefile | 2 +-
lib/chacha20.c | 79 ++++++++++++
6 files changed, 468 insertions(+), 160 deletions(-)
create mode 100644 lib/chacha20.c
^ permalink raw reply
* Re: [GIT PULL] /dev/random driver changes for 4.8
From: Stephen Rothwell @ 2016-07-25 7:15 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Linus Torvalds, linux-kernel, linux-crypto
In-Reply-To: <20160725064424.GA29098@thunk.org>
Hi Ted,
On Mon, 25 Jul 2016 02:44:24 -0400 Theodore Ts'o <tytso@mit.edu> wrote:
>
> The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
>
> Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus
>
> for you to fetch changes up to 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec:
>
> random: strengthen input validation for RNDADDTOENTCNT (2016-07-03 17:09:33 -0400)
Of course none of this has been in linux-next since the random tree was
dropped in March because it had not been updated for more than a year at
that point.
However, at least half of these look like bug fixes (cced to stable).
Should I reinstate the random tree to linux-next?
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Crypto Update for 4.8
From: Herbert Xu @ 2016-07-25 10:53 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160516071608.GA1594@gondor.apana.org.au>
Hi Linus:
Here is the crypto update for 4.8:
API:
* First part of skcipher low-level conversions.
* Add KPP (Key-agreement Protocol Primitives) interface.
Algorithms:
* Fix IPsec/cryptd reordering issues that affects aesni.
* RSA no longer does explicit leading zero removal.
* Add SHA3.
* Add DH.
* Add ECDH.
* Improve DRBG performance by not doing CTR by hand.
Drivers:
* Add x86 AVX2 multibuffer SHA256/512.
* Add POWER8 optimised crc32c.
* Add xts support to vmx.
* Add DH support to qat.
* Add RSA support to caam.
* Add Layerscape support to caam.
* Add SEC1 AEAD support to talitos.
* Improve performance by chaining requests in marvell/cesa.
* Add support for Araneus Alea I USB RNG.
* Add support for Broadcom BCM5301 RNG.
* Add support for Amlogic Meson RNG.
* Add support Broadcom NSP SoC RNG.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Amitoj Kaur Chawla (1):
crypto: bfin_crc - Simplify use of devm_ioremap_resource
Andrea Gelmini (2):
crypto: doc - Fix typo
crypto: powerpc - Fix typo
Anton Blanchard (2):
powerpc: define FUNC_START/FUNC_END
crypto: powerpc - Add POWER8 optimised crc32c
Arnd Bergmann (2):
crypto: caam - fix misspelled upper_32_bits
crypto: ux500 - do not build with -O0
Ben Dooks (1):
hwrng: exynos - fixup IO accesors
Bhaktipriya Shridhar (1):
crypto: qat - Remove deprecated create_workqueue
Bin Liu (2):
crypto: omap-sham - set sw fallback to 240 bytes
crypto: omap-sham - increase cra_proirity to 400
Bob Ham (2):
hwrng: chaoskey - Add support for Araneus Alea I USB RNG
hwrng: chaoskey - Fix URB warning due to timeout on Alea
Conor McLoughlin (1):
crypto: qat - Use alternative reset methods depending on the specific device
Cristian Stoica (1):
crypto: caam - fix offset field in hw sg entries
Dan Carpenter (2):
crypto: drbg - fix an error code in drbg_init_sym_kernel()
crypto: nx - off by one bug in nx_of_update_msc()
Florian Fainelli (2):
hwrng: bcm2835 - Add support for Broadcom BCM5301x
Documentation: devicetree: bindings: Add BCM5301x binding
Geert Uytterhoeven (2):
MAINTAINERS: Add file patterns for crypto device tree bindings
MAINTAINERS: Add file patterns for rng device tree bindings
Geliang Tang (1):
crypto: skcipher - remove unused header cpumask.h
Giovanni Cabiddu (1):
crypto: hash - shrink hash down to two types
Harsh Jain (1):
crypto: authenc - Remove redundant sg_init_table call.
Herbert Xu (63):
crypto: gcm - Filter out async ghash if necessary
Revert "crypto: user - no parsing of CRYPTO_MSG_GETALG"
crypto: chacha20-simd - Use generic code for small requests
crypto: cryptd - Add helpers to check whether a tfm is queued
crypto: aesni - Fix cryptd reordering problem on gcm
crypto: ablk_helper - Fix cryptd reordering
crypto: ghash-clmulni - Fix cryptd reordering
crypto: ghash-ce - Fix cryptd reordering
KEYS: Use skcipher for big keys
crypto: tcrypt - Use unsigned long for mb ahash cycle counter
crypto: tcrypt - Fix memory leaks/crashes in multibuffer hash speed test
crypto: authenc - Consider ahash ASYNC bit
crypto: ahash - Add padding in crypto_ahash_extsize
crypto: tcrypt - Use skcipher
crypto: aesni - Use crypto_cipher to derive rfc4106 subkey
crypto: ccp - Use skcipher for fallback
crypto: mxs-dcp - Use skcipher for fallback
crypto: picoxcell - Use skcipher for fallback
crypto: qce - Use skcipher for fallback
crypto: sahara - Use skcipher for fallback
crypto: s390/aes - Use skcipher for fallback
crypto: api - Add crypto_inst_setname
crypto: tcrypt - Add speed test for cts
crypto: testmgr - Allow leading zeros in RSA
crypto: rsa - Generate fixed-length output
lib/mpi: Do not do sg_virt
crypto: rsa-pkcs1pad - Require hash to be present
crypto: rsa-pkcs1pad - Remove bogus page splitting
crypto: rsa-pkcs1pad - Always use GFP_KERNEL
crypto: rsa-pkcs1pad - Move key size check to setkey
crypto: rsa-pkcs1pad - Avoid copying output when possible
crypto: tcrypt - Do not bail on EINPROGRESS in multibuffer hash test
crypto: rsa-pkcs1pad - Fix regression from leading zeros
crypto: skcipher - Add low-level skcipher interface
crypto: null - Add new default null skcipher
crypto: aead - Add chunk size
crypto: authenc - Use skcipher
crypto: authencesn - Use skcipher
crypto: ctr - Use skcipher in rfc3686
crypto: ccm - Use skcipher
crypto: gcm - Use skcipher
crypto: chacha20poly1305 - Use skcipher
crypto: aead - Add skcipher null for IV generators
crypto: echainiv - Use skcipher
crypto: seqiv - Use skcipher
crypto: aead - Remove blkcipher null for IV generators
crypto: null - Remove default null blkcipher
crypto: cts - Convert to skcipher
crypto: user - Remove crypto_lookup_skcipher call
crypto: skcipher - Remove top-level givcipher interface
crypto: omap - Stop using crypto scatterwalk_bytes_sglen
crypto: scatterwalk - Remove scatterwalk_bytes_sglen
crypto: scatterwalk - Add no-copy support to copychunks
crypto: api - Optimise away crypto_yield when hard preemption is on
crypto: scatterwalk - Fix test in scatterwalk_done
crypto: scatterwalk - Remove unnecessary advance in scatterwalk_pagedone
crypto: scatterwalk - Remove unnecessary BUG in scatterwalk_start
crypto: scatterwalk - Inline start/map/done
crypto: testmgr - Print akcipher algorithm name
crypto: skcipher - Add comment for skcipher_alg->base
crypto: vmx - Fix aes_p8_xts_decrypt build failure
Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Horia Geantă (7):
asm-generic/io.h: allow barriers in io{read,write}{16,32}be
asm-generic/io.h: add io{read,write}64 accessors
arm64: add io{read,write}64be accessors
powerpc: add io{read,write}64 accessors
crypto: caam - handle core endianness != caam endianness
crypto: caam - add ARCH_LAYERSCAPE to supported architectures
arm64: dts: ls1043a: add crypto node
Jeff Garzik (1):
crypto: sha3 - Add SHA-3 hash algorithm
Krzysztof Kozlowski (2):
crypto: s5p-sss - Use consistent indentation for variables and members
crypto: tcrypt - Fix mixing printk/pr_err and obvious indentation issues
LEROY Christophe (7):
crypto: talitos - using helpers for all talitos_ptr operations
crypto: talitos - move mapping helpers before IPSEC functions
crypto: talitos - making mapping helpers more generic
crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU
crypto: talitos - sg_to_link_tbl() not used anymore, remove it
crypto: talitos - implement cra_priority
crypto: talitos - templates for AEAD using HMAC_SNOOP_NO_AFEU
Leonidas S. Barbosa (1):
crypto: vmx - Adding support for XTS
Lokesh Vutla (2):
crypto: omap-aes - Fix registration of algorithms
crypto: omap - do not call dmaengine_terminate_all
Masanari Iida (1):
crypto: doc - Fix double words "the the" in crypto-API.tmpl
Maxime Coquelin (1):
hwrng: stm32 - fix maybe uninitialized variable warning
Megha Dey (15):
crypto: sha1-mb - stylistic cleanup
crypto: sha1-mb - async implementation for sha1-mb
crypto: sha256-mb - SHA256 multibuffer job manager and glue code
crypto: sha256-mb - Enable multibuffer support
crypto: sha256-mb - submit/flush routines for AVX2
crypto: sha256-mb - Algorithm data structures
crypto: sha256-mb - Crypto computation (x8 AVX2)
crypto: tcrypt - Add speed tests for SHA multibuffer algorithms
crypto: sha1-mb - rename sha-mb to sha1-mb
crypto: sha512-mb - SHA512 multibuffer job manager and glue code
crypto: sha512-mb - Enable SHA512 multibuffer support
crypto: sha512-mb - submit/flush routines for AVX2
crypto: sha512-mb - Algorithm data structures
crypto: sha512-mb - Crypto computation (x4 AVX2)
crypto: tcrypt - Add new mode for sha512_mb
Neil Armstrong (1):
hwrng: meson - Add Amlogic Meson Hardware Random Generator
Nicolai Stange (8):
lib/mpi: purge mpi_set_buffer()
lib/mpi: mpi_read_raw_data(): purge redundant clearing of nbits
lib/mpi: mpi_read_raw_data(): fix nbits calculation
lib/mpi: mpi_read_from_buffer(): return error code
lib/digsig: digsig_verify_rsa(): return -EINVAL if modulo length is zero
lib/mpi: mpi_read_from_buffer(): return -EINVAL upon too short buffer
lib/mpi: mpi_read_from_buffer(): sanitize short buffer printk
lib/mpi: refactor mpi_read_from_buffer() in terms of mpi_read_raw_data()
Nishanth Menon (1):
hwrng: omap - Fix assumption that runtime_get_sync will always succeed
Paulo Flabiano Smorigo (2):
crypto: vmx - Adding asm subroutines for XTS
crypto: vmx - Ignore generated files
Romain Perier (11):
crypto: marvell - Add a macro constant for the size of the crypto queue
crypto: marvell - Check engine is not already running when enabling a req
crypto: marvell - Fix wrong type check in dma functions
crypto: marvell - Copy IV vectors by DMA transfers for acipher requests
crypto: marvell - Move tdma chain out of mv_cesa_tdma_req and remove it
crypto: marvell - Add a complete operation for async requests
crypto: marvell - Move SRAM I/O operations to step functions
crypto: marvell - Add load balancing between engines
crypto: marvell - Add support for chaining crypto requests in TDMA mode
crypto: marvell - Increase the size of the crypto queue
crypto: marvell - Fix wrong flag used for GFP in mv_cesa_dma_add_iv_op
Salvatore Benedetto (10):
crypto: kpp - Key-agreement Protocol Primitives API (KPP)
crypto: dh - Add DH software implementation
crypto: ecdh - Add ECDH software support
crypto: qat - Switch to new rsa_helper functions
crypto: testmgr - Set err before proceeding
crypto: rsa - Store rest of the private key components
crypto: testmgr - Add 4K private key to RSA testvector
crypto: qat - Add RSA CRT mode
crypto: qat - Add DH support
crypto: qat - Stop dropping leading zeros from RSA output
Stephan Mueller (8):
crypto: sha-ssse3 - add MODULE_ALIAS
crypto: user - no parsing of CRYPTO_MSG_GETALG
crypto: drbg - reduce number of setkey calls
crypto: drbg - use CTR AES instead of ECB AES
crypto: drbg - use aligned buffers
crypto: drbg - use full CTR AES for update
crypto: drbg - avoid duplicate maintenance of key
crypto: jitterentropy - use ktime_get_ns as fallback
Stephen Rothwell (1):
crypto: ecdh - make ecdh_shared_secret unique
Tadeusz Struk (3):
crypto: qat - fix typos sizeof for ctx
MAINTAINERS: update maintainer for qat
crypto: rsa-pkcs1pad - fix rsa-pkcs1pad request struct
Tero Kristo (2):
crypto: omap-sham - use runtime_pm autosuspend for clock handling
crypto: omap-sham - change queue size from 1 to 10
Tim Chen (1):
crypto: sha-mb - Cleanup code to use || instead of |
Tudor Ambarus (3):
crypto: rsa - return raw integers for the ASN.1 parser
crypto: caam - replace deprecated EXTRA_CFLAGS
crypto: caam - add support for RSA algorithm
Wu Fengguang (1):
crypto: drbg - fix semicolon.cocci warnings
Yendapally Reddy Dhananjaya Reddy (4):
dt-bindings: rng: Northstar Plus SoC rng bindings
hwrng: bcm2835 - Support Broadcom NSP SoC rng
ARM: dts: nsp: Add rng device tree entry
hwrng: bcm2835 - Read as much data as available
raveendra padasalagi (2):
crypto: sha3 - Add SHA-3 Test's in tcrypt
crypto: sha3 - Add HMAC-SHA3 test modes and test vectors
Documentation/DocBook/crypto-API.tmpl | 4 +-
Documentation/crypto/asymmetric-keys.txt | 2 +-
.../devicetree/bindings/rng/brcm,bcm2835.txt | 8 +-
MAINTAINERS | 5 +-
arch/arm/boot/dts/bcm-nsp.dtsi | 5 +
arch/arm/crypto/ghash-ce-glue.c | 40 +-
arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts | 4 +
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 43 +
arch/arm64/include/asm/io.h | 4 +-
arch/powerpc/crypto/Makefile | 2 +
arch/powerpc/crypto/aes-spe-regs.h | 2 +-
arch/powerpc/crypto/crc32c-vpmsum_asm.S | 1553 ++++++++++++++++
arch/powerpc/crypto/crc32c-vpmsum_glue.c | 167 ++
arch/powerpc/include/asm/ppc-opcode.h | 12 +
arch/powerpc/include/asm/ppc_asm.h | 3 +
arch/powerpc/kernel/iomap.c | 24 +
arch/s390/crypto/aes_s390.c | 113 +-
arch/x86/crypto/Makefile | 4 +-
arch/x86/crypto/aesni-intel_glue.c | 94 +-
arch/x86/crypto/chacha20_glue.c | 2 +-
arch/x86/crypto/ghash-clmulni-intel_glue.c | 40 +-
arch/x86/crypto/{sha-mb => sha1-mb}/Makefile | 0
arch/x86/crypto/{sha-mb => sha1-mb}/sha1_mb.c | 288 +--
.../{sha-mb/sha_mb_ctx.h => sha1-mb/sha1_mb_ctx.h} | 2 +-
.../{sha-mb/sha_mb_mgr.h => sha1-mb/sha1_mb_mgr.h} | 0
.../{sha-mb => sha1-mb}/sha1_mb_mgr_datastruct.S | 0
.../{sha-mb => sha1-mb}/sha1_mb_mgr_flush_avx2.S | 0
.../{sha-mb => sha1-mb}/sha1_mb_mgr_init_avx2.c | 2 +-
.../{sha-mb => sha1-mb}/sha1_mb_mgr_submit_avx2.S | 0
arch/x86/crypto/{sha-mb => sha1-mb}/sha1_x8_avx2.S | 0
arch/x86/crypto/sha1_ssse3_glue.c | 6 +
arch/x86/crypto/sha256-mb/Makefile | 11 +
arch/x86/crypto/sha256-mb/sha256_mb.c | 1030 +++++++++++
arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 136 ++
arch/x86/crypto/sha256-mb/sha256_mb_mgr.h | 108 ++
.../crypto/sha256-mb/sha256_mb_mgr_datastruct.S | 304 ++++
.../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S | 304 ++++
.../x86/crypto/sha256-mb/sha256_mb_mgr_init_avx2.c | 65 +
.../crypto/sha256-mb/sha256_mb_mgr_submit_avx2.S | 215 +++
arch/x86/crypto/sha256-mb/sha256_x8_avx2.S | 593 +++++++
arch/x86/crypto/sha256_ssse3_glue.c | 10 +
arch/x86/crypto/sha512-mb/Makefile | 11 +
arch/x86/crypto/sha512-mb/sha512_mb.c | 1046 +++++++++++
arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 130 ++
arch/x86/crypto/sha512-mb/sha512_mb_mgr.h | 104 ++
.../crypto/sha512-mb/sha512_mb_mgr_datastruct.S | 281 +++
.../crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S | 291 +++
.../x86/crypto/sha512-mb/sha512_mb_mgr_init_avx2.c | 67 +
.../crypto/sha512-mb/sha512_mb_mgr_submit_avx2.S | 222 +++
arch/x86/crypto/sha512-mb/sha512_x4_avx2.S | 529 ++++++
arch/x86/crypto/sha512_ssse3_glue.c | 6 +
crypto/Kconfig | 77 +
crypto/Makefile | 12 +-
crypto/ablk_helper.c | 6 +-
crypto/ablkcipher.c | 223 ---
crypto/aead.c | 16 +-
crypto/ahash.c | 6 +-
crypto/algapi.c | 24 +-
crypto/authenc.c | 116 +-
crypto/authencesn.c | 106 +-
crypto/blkcipher.c | 185 --
crypto/ccm.c | 72 +-
crypto/chacha20poly1305.c | 89 +-
crypto/chainiv.c | 317 ----
crypto/cryptd.c | 132 +-
crypto/crypto_null.c | 11 +-
crypto/crypto_user.c | 57 +-
crypto/ctr.c | 183 +-
crypto/cts.c | 495 +++---
crypto/dh.c | 189 ++
crypto/dh_helper.c | 95 +
crypto/drbg.c | 269 ++-
crypto/ecc.c | 1018 +++++++++++
crypto/ecc.h | 83 +
crypto/ecc_curve_defs.h | 57 +
crypto/ecdh.c | 151 ++
crypto/ecdh_helper.c | 86 +
crypto/echainiv.c | 16 +-
crypto/eseqiv.c | 242 ---
crypto/gcm.c | 115 +-
crypto/jitterentropy-kcapi.c | 22 +-
crypto/kpp.c | 123 ++
crypto/mcryptd.c | 132 +-
crypto/rsa-pkcs1pad.c | 325 ++--
crypto/rsa.c | 113 +-
crypto/rsa_helper.c | 172 +-
crypto/rsaprivkey.asn1 | 10 +-
crypto/scatterwalk.c | 81 +-
crypto/seqiv.c | 176 +-
crypto/sha3_generic.c | 300 ++++
crypto/skcipher.c | 196 +-
crypto/tcrypt.c | 442 +++--
crypto/testmgr.c | 288 ++-
crypto/testmgr.h | 1036 ++++++++++-
drivers/char/hw_random/Kconfig | 16 +-
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/bcm2835-rng.c | 47 +-
drivers/char/hw_random/exynos-rng.c | 4 +-
drivers/char/hw_random/meson-rng.c | 131 ++
drivers/char/hw_random/omap-rng.c | 16 +-
drivers/char/hw_random/stm32-rng.c | 10 +-
drivers/crypto/bfin_crc.c | 5 -
drivers/crypto/caam/Kconfig | 18 +-
drivers/crypto/caam/Makefile | 4 +-
drivers/crypto/caam/caamhash.c | 5 +-
drivers/crypto/caam/caampkc.c | 607 +++++++
drivers/crypto/caam/caampkc.h | 70 +
drivers/crypto/caam/compat.h | 3 +
drivers/crypto/caam/ctrl.c | 125 +-
drivers/crypto/caam/desc.h | 11 +-
drivers/crypto/caam/desc_constr.h | 51 +-
drivers/crypto/caam/jr.c | 22 +-
drivers/crypto/caam/pdb.h | 188 +-
drivers/crypto/caam/pkc_desc.c | 36 +
drivers/crypto/caam/regs.h | 151 +-
drivers/crypto/caam/sg_sw_sec4.h | 17 +-
drivers/crypto/ccp/ccp-crypto-aes-xts.c | 43 +-
drivers/crypto/ccp/ccp-crypto.h | 3 +-
drivers/crypto/marvell/cesa.c | 142 +-
drivers/crypto/marvell/cesa.h | 120 +-
drivers/crypto/marvell/cipher.c | 157 +-
drivers/crypto/marvell/hash.c | 150 +-
drivers/crypto/marvell/tdma.c | 130 +-
drivers/crypto/mxs-dcp.c | 47 +-
drivers/crypto/nx/nx.c | 2 +-
drivers/crypto/omap-aes.c | 36 +-
drivers/crypto/omap-des.c | 14 +-
drivers/crypto/omap-sham.c | 47 +-
drivers/crypto/picoxcell_crypto.c | 60 +-
drivers/crypto/qat/Kconfig | 3 +-
drivers/crypto/qat/qat_c3xxx/adf_c3xxx_hw_data.c | 1 +
drivers/crypto/qat/qat_c62x/adf_c62x_hw_data.c | 1 +
drivers/crypto/qat/qat_common/Makefile | 11 -
drivers/crypto/qat/qat_common/adf_accel_devices.h | 1 +
drivers/crypto/qat/qat_common/adf_aer.c | 49 +-
drivers/crypto/qat/qat_common/adf_common_drv.h | 2 +
drivers/crypto/qat/qat_common/adf_sriov.c | 2 +-
drivers/crypto/qat/qat_common/adf_vf_isr.c | 2 +-
drivers/crypto/qat/qat_common/qat_algs.c | 8 +-
drivers/crypto/qat/qat_common/qat_asym_algs.c | 872 +++++++--
drivers/crypto/qat/qat_common/qat_rsaprivkey.asn1 | 11 -
drivers/crypto/qat/qat_common/qat_rsapubkey.asn1 | 4 -
.../crypto/qat/qat_dh895xcc/adf_dh895xcc_hw_data.c | 1 +
drivers/crypto/qce/ablkcipher.c | 27 +-
drivers/crypto/qce/cipher.h | 2 +-
drivers/crypto/s5p-sss.c | 80 +-
drivers/crypto/sahara.c | 112 +-
drivers/crypto/talitos.c | 672 ++++---
drivers/crypto/ux500/cryp/Makefile | 6 +-
drivers/crypto/ux500/hash/Makefile | 2 +-
drivers/crypto/vmx/.gitignore | 2 +
drivers/crypto/vmx/Makefile | 2 +-
drivers/crypto/vmx/aes_xts.c | 190 ++
drivers/crypto/vmx/aesp8-ppc.h | 4 +
drivers/crypto/vmx/aesp8-ppc.pl | 1863 +++++++++++++++++++-
drivers/crypto/vmx/vmx.c | 2 +
drivers/usb/misc/Kconfig | 11 +-
drivers/usb/misc/chaoskey.c | 21 +-
include/asm-generic/io.h | 71 +-
include/asm-generic/iomap.h | 8 +
include/crypto/aead.h | 12 +-
include/crypto/algapi.h | 4 +
include/crypto/cryptd.h | 5 +
include/crypto/dh.h | 29 +
include/crypto/drbg.h | 12 +
include/crypto/ecdh.h | 30 +
include/crypto/internal/aead.h | 21 +
include/crypto/internal/geniv.h | 2 +-
include/crypto/internal/hash.h | 12 +-
include/crypto/internal/kpp.h | 64 +
include/crypto/internal/rsa.h | 42 +-
include/crypto/internal/skcipher.h | 122 +-
include/crypto/kpp.h | 330 ++++
include/crypto/mcryptd.h | 8 +-
include/crypto/null.h | 12 +-
include/crypto/scatterwalk.h | 48 +-
include/crypto/sha3.h | 29 +
include/crypto/skcipher.h | 207 ++-
include/linux/crypto.h | 31 +-
include/linux/mpi.h | 3 +-
include/uapi/linux/cryptouser.h | 5 +
lib/digsig.c | 16 +-
lib/mpi/mpicoder.c | 249 +--
security/keys/big_key.c | 30 +-
184 files changed, 19350 insertions(+), 4261 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: [PATCH] crypto: marvell - Update cache with input sg only when it is unmapped
From: Boris Brezillon @ 2016-07-25 12:33 UTC (permalink / raw)
To: Romain Perier
Cc: Arnaud Ebalard, David S. Miller, linux-crypto, Thomas Petazzoni,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement
In-Reply-To: <1469195184-4700-1-git-send-email-romain.perier@free-electrons.com>
On Fri, 22 Jul 2016 15:46:24 +0200
Romain Perier <romain.perier@free-electrons.com> wrote:
> So far, the cache of the ahash requests was updated from the 'complete'
> operation. This complete operation is called from mv_cesa_tdma_process
> before the cleanup operation, which means that the content of req->src
> can be read and copied when it is still mapped. This commit fixes the
> issue by moving this cache update from mv_cesa_ahash_complete to
> mv_cesa_ahash_req_cleanup, so the copy is done once the sglist is
> unmapped.
>
> Fixes: 1bf6682cb31d ("crypto: marvell - Add a complete operation for..")
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/crypto/marvell/hash.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index c35912b..82e0f4e6 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -315,12 +315,6 @@ static void mv_cesa_ahash_complete(struct crypto_async_request *req)
> for (i = 0; i < digsize / 4; i++)
> creq->state[i] = readl_relaxed(engine->regs + CESA_IVDIG(i));
>
> - if (creq->cache_ptr)
> - sg_pcopy_to_buffer(ahashreq->src, creq->src_nents,
> - creq->cache,
> - creq->cache_ptr,
> - ahashreq->nbytes - creq->cache_ptr);
> -
> if (creq->last_req) {
> /*
> * Hardware's MD5 digest is in little endian format, but
> @@ -365,6 +359,12 @@ static void mv_cesa_ahash_req_cleanup(struct crypto_async_request *req)
> mv_cesa_ahash_last_cleanup(ahashreq);
>
> mv_cesa_ahash_cleanup(ahashreq);
> +
> + if (creq->cache_ptr)
> + sg_pcopy_to_buffer(ahashreq->src, creq->src_nents,
> + creq->cache,
> + creq->cache_ptr,
> + ahashreq->nbytes - creq->cache_ptr);
> }
>
> static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops = {
^ permalink raw reply
* Re: [GIT PULL] /dev/random driver changes for 4.8
From: Theodore Ts'o @ 2016-07-25 14:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linus Torvalds, linux-kernel, linux-crypto
In-Reply-To: <20160725171515.737d61ae@canb.auug.org.au>
On Mon, Jul 25, 2016 at 05:15:15PM +1000, Stephen Rothwell wrote:
> Hi Ted,
>
> On Mon, 25 Jul 2016 02:44:24 -0400 Theodore Ts'o <tytso@mit.edu> wrote:
> >
> > The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
> >
> > Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus
> >
> > for you to fetch changes up to 86a574de4590ffe6fd3f3ca34cdcf655a78e36ec:
> >
> > random: strengthen input validation for RNDADDTOENTCNT (2016-07-03 17:09:33 -0400)
>
> Of course none of this has been in linux-next since the random tree was
> dropped in March because it had not been updated for more than a year at
> that point.
>
> However, at least half of these look like bug fixes (cced to stable).
>
> Should I reinstate the random tree to linux-next?
Yes, please do. It was getting zero-day checks, and I assumed it was
in linux-next; I should have checked, though.
- Ted
^ permalink raw reply
* [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
From: Keith Packard @ 2016-07-25 20:07 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, linux-kernel, Keith Packard
Instead of having only one hwrng feeding /dev/random at a time, maintain
a list of devices and cycle between them when filling the entropy pool.
Signed-off-by: Keith Packard <keithp@keithp.com>
---
drivers/char/hw_random/core.c | 155 +++++++++++++++++++++++++++---------------
include/linux/hw_random.h | 2 +
2 files changed, 104 insertions(+), 53 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d..97fd4a7 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -51,10 +51,10 @@
#define RNG_MISCDEV_MINOR 183 /* official */
-static struct hwrng *current_rng;
+static LIST_HEAD(active_rng);
static struct task_struct *hwrng_fill;
static LIST_HEAD(rng_list);
-/* Protects rng_list and current_rng */
+/* Protects rng_list and active_rng */
static DEFINE_MUTEX(rng_mutex);
/* Protects rng read functions, data_avail, rng_buffer and rng_fillbuf */
static DEFINE_MUTEX(reading_mutex);
@@ -70,7 +70,6 @@ module_param(default_quality, ushort, 0644);
MODULE_PARM_DESC(default_quality,
"default entropy content of hwrng per mill");
-static void drop_current_rng(void);
static int hwrng_init(struct hwrng *rng);
static void start_khwrngd(void);
@@ -104,31 +103,65 @@ static inline void cleanup_rng(struct kref *kref)
complete(&rng->cleanup_done);
}
-static int set_current_rng(struct hwrng *rng)
+static unsigned short rng_quality(struct hwrng *rng)
+{
+ unsigned short quality;
+
+ quality = current_quality;
+ if (!quality) {
+ quality = rng->quality;
+ if (!quality)
+ quality = default_quality;
+ }
+ if (quality > 1024)
+ quality = 1024;
+ return quality;
+}
+
+static int add_active_rng(struct hwrng *rng)
{
int err;
BUG_ON(!mutex_is_locked(&rng_mutex));
+ if (rng->is_active)
+ return 0;
+
err = hwrng_init(rng);
if (err)
return err;
- drop_current_rng();
- current_rng = rng;
+ if (rng_quality(rng) != 0) {
+ rng->is_active = true;
+ list_add(&rng->active, &active_rng);
+ if (!hwrng_fill)
+ start_khwrngd();
+ }
return 0;
}
-static void drop_current_rng(void)
+static int drop_active_rng(struct hwrng *rng)
{
BUG_ON(!mutex_is_locked(&rng_mutex));
- if (!current_rng)
- return;
+ if (!rng->is_active)
+ return 0;
+
+ list_del(&rng->active);
+ rng->is_active = false;
/* decrease last reference for triggering the cleanup */
- kref_put(¤t_rng->ref, cleanup_rng);
- current_rng = NULL;
+ kref_put(&rng->ref, cleanup_rng);
+
+ if (list_empty(&active_rng) && hwrng_fill)
+ kthread_stop(hwrng_fill);
+
+ return 0;
+}
+
+static struct hwrng *first_active_rng(void)
+{
+ return list_first_entry_or_null(&active_rng, struct hwrng, active);
}
/* Returns ERR_PTR(), NULL or refcounted hwrng */
@@ -139,18 +172,32 @@ static struct hwrng *get_current_rng(void)
if (mutex_lock_interruptible(&rng_mutex))
return ERR_PTR(-ERESTARTSYS);
- rng = current_rng;
+ rng = first_active_rng();
if (rng)
kref_get(&rng->ref);
mutex_unlock(&rng_mutex);
+
return rng;
}
+static int next_rng(void)
+{
+ if (mutex_lock_interruptible(&rng_mutex))
+ return -ERESTARTSYS;
+
+ if (!list_empty(&active_rng) && !list_is_singular(&active_rng))
+ list_rotate_left(&active_rng);
+
+ mutex_unlock(&rng_mutex);
+
+ return 0;
+}
+
static void put_rng(struct hwrng *rng)
{
/*
- * Hold rng_mutex here so we serialize in case they set_current_rng
+ * Hold rng_mutex here so we serialize in case they add_active_rng
* on rng again immediately.
*/
mutex_lock(&rng_mutex);
@@ -178,15 +225,6 @@ static int hwrng_init(struct hwrng *rng)
skip_init:
add_early_randomness(rng);
- current_quality = rng->quality ? : default_quality;
- if (current_quality > 1024)
- current_quality = 1024;
-
- if (current_quality == 0 && hwrng_fill)
- kthread_stop(hwrng_fill);
- if (current_quality > 0 && !hwrng_fill)
- start_khwrngd();
-
return 0;
}
@@ -246,6 +284,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user *buf,
bytes_read = rng_get_data(rng, rng_buffer,
rng_buffer_size(),
!(filp->f_flags & O_NONBLOCK));
+ next_rng();
if (bytes_read < 0) {
err = bytes_read;
goto out_unlock_reading;
@@ -320,20 +359,30 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
const char *buf, size_t len)
{
int err;
+ int add = 1;
struct hwrng *rng;
err = mutex_lock_interruptible(&rng_mutex);
if (err)
return -ERESTARTSYS;
+ if (*buf == '-') {
+ add = 0;
+ buf++;
+ } else if (*buf == '+') {
+ add = 1;
+ buf++;
+ }
err = -ENODEV;
list_for_each_entry(rng, &rng_list, list) {
if (sysfs_streq(rng->name, buf)) {
- err = 0;
- if (rng != current_rng)
- err = set_current_rng(rng);
+ if (add)
+ err = add_active_rng(rng);
+ else
+ err = drop_active_rng(rng);
break;
}
}
+
mutex_unlock(&rng_mutex);
return err ? : len;
@@ -343,17 +392,26 @@ static ssize_t hwrng_attr_current_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- ssize_t ret;
+ int err;
struct hwrng *rng;
- rng = get_current_rng();
- if (IS_ERR(rng))
- return PTR_ERR(rng);
-
- ret = snprintf(buf, PAGE_SIZE, "%s\n", rng ? rng->name : "none");
- put_rng(rng);
+ err = mutex_lock_interruptible(&rng_mutex);
+ if (err)
+ return -ERESTARTSYS;
+ buf[0] = '\0';
+ if (list_empty(&active_rng)) {
+ strlcat(buf, "none", PAGE_SIZE);
+ } else {
+ list_for_each_entry(rng, &active_rng, active) {
+ if (rng != first_active_rng())
+ strlcat(buf, " ", PAGE_SIZE);
+ strlcat(buf, rng->name, PAGE_SIZE);
+ }
+ }
+ strlcat(buf, "\n", PAGE_SIZE);
+ mutex_unlock(&rng_mutex);
- return ret;
+ return strlen(buf);
}
static ssize_t hwrng_attr_available_show(struct device *dev,
@@ -412,6 +470,7 @@ static int hwrng_fillfn(void *unused)
rng = get_current_rng();
if (IS_ERR(rng) || !rng)
break;
+ next_rng();
mutex_lock(&reading_mutex);
rc = rng_get_data(rng, rng_fillbuf,
rng_buffer_size(), 1);
@@ -442,7 +501,7 @@ static void start_khwrngd(void)
int hwrng_register(struct hwrng *rng)
{
int err = -EINVAL;
- struct hwrng *old_rng, *tmp;
+ struct hwrng *tmp;
if (rng->name == NULL ||
(rng->data_read == NULL && rng->read == NULL))
@@ -472,19 +531,18 @@ int hwrng_register(struct hwrng *rng)
goto out_unlock;
}
+ rng->is_active = false;
+
init_completion(&rng->cleanup_done);
complete(&rng->cleanup_done);
- old_rng = current_rng;
- err = 0;
- if (!old_rng) {
- err = set_current_rng(rng);
- if (err)
- goto out_unlock;
- }
+ err = add_active_rng(rng);
+ if (err)
+ goto out_unlock;
+
list_add_tail(&rng->list, &rng_list);
- if (old_rng && !rng->init) {
+ if (!rng->init) {
/*
* Use a new device's input to add some randomness to
* the system. If this rng device isn't going to be
@@ -507,16 +565,7 @@ void hwrng_unregister(struct hwrng *rng)
mutex_lock(&rng_mutex);
list_del(&rng->list);
- if (current_rng == rng) {
- drop_current_rng();
- if (!list_empty(&rng_list)) {
- struct hwrng *tail;
-
- tail = list_entry(rng_list.prev, struct hwrng, list);
-
- set_current_rng(tail);
- }
- }
+ drop_active_rng(rng);
if (list_empty(&rng_list)) {
mutex_unlock(&rng_mutex);
@@ -579,7 +628,7 @@ static int __init hwrng_modinit(void)
static void __exit hwrng_modexit(void)
{
mutex_lock(&rng_mutex);
- BUG_ON(current_rng);
+ WARN_ON(!list_empty(&active_rng));
kfree(rng_buffer);
kfree(rng_fillbuf);
mutex_unlock(&rng_mutex);
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index 4f7d8f4..c655563 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -45,7 +45,9 @@ struct hwrng {
unsigned short quality;
/* internal. */
+ bool is_active;
struct list_head list;
+ struct list_head active;
struct kref ref;
struct completion cleanup_done;
};
--
2.8.1
^ permalink raw reply related
* Re: [GIT PULL] /dev/random driver changes for 4.8
From: Stephen Rothwell @ 2016-07-25 21:51 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Linus Torvalds, linux-kernel, linux-crypto
In-Reply-To: <20160725142407.GG10966@thunk.org>
Hi Ted,
On Mon, 25 Jul 2016 10:24:07 -0400 Theodore Ts'o <tytso@mit.edu> wrote:
>
> On Mon, Jul 25, 2016 at 05:15:15PM +1000, Stephen Rothwell wrote:
> >
> > Should I reinstate the random tree to linux-next?
>
> Yes, please do. It was getting zero-day checks, and I assumed it was
> in linux-next; I should have checked, though.
Done from today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* a few questions on AF_ALG specification (AEAD, socket/connection, ...)
From: Nicolas Brunie @ 2016-07-26 11:48 UTC (permalink / raw)
To: Linux Crypto Mailing List
Hi All,
I am developping a driver for a crypto offloading solution which
uses the AF_ALG interface. I am trying to stay as close as possible to
the specification but apart from the kernel crypto source code and a few
documents (such as
https://www.kernel.org/doc/htmldocs/crypto-API/ch04s06.html ) I have not
found a lot of details on AF_ALG specification and many points are not
very clear to me, it someone could point me towards reference to answer
the following questions it will be deeply appreciated.
*
**
Socket / Connection :
Is it legal to open multiple connections on an AF_ALG socket ? How is
the behavior defined
*From what I could test, at least for digests, multiple connections are
OK, but it seems odd to allow multiple connection to a cipher while
using a**shared key and multiple IVs. One of the use I could think of
will be parallelizing several encryption/decryption with the same
symmetric key.
*
Is it true that the key (defined via setsockopt) is common to all the
connections but the IV (defined through message control header) is
specific to each connection ?
*
*
Send/Recv interleaving
When computing a digest (e.g. sha256) it seems the recv call is
triggering the end of the digest accumulation, such a behavior can be
obtained by using/not using MSG_MORE flags, which *of the two*the
canonical way to compute a hash over several send messages ? It does not
seem possible to compute a partial digest (through a recv call) and then
continue accumulating through other send calls (apart from the security
risk of exposing a te*mporary digest, is there a reason why the recv
ends a digest computation ?)*.*
*
AES-GCM / AEAD
Does the aead_assoclen must be set once and for all for each stream or
is it a by message option ?
Option 0: set aead_assoclen during the first sendmsg and then stream
accross several sendmsg the full AAD and then the full plaintext/ciphertext
Option 1: set aead_assoclen for each of the first sendmsg containing aad
data. Once the aead_assoclen is strictly less than the msg’s data length
then the next messages must have aead_assoclen set to 0
*
best regards,
Nicolas Brunie
^ permalink raw reply
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