* Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported
From: Michael Ellerman @ 2016-07-19 9:13 UTC (permalink / raw)
To: Herbert Xu
Cc: alastair, linux-kernel, paulus, linux-crypto,
Alastair D'Silva, linuxppc-dev, davem
In-Reply-To: <20160719035939.GA20847@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Jul 19, 2016 at 11:01:55AM +1000, Michael Ellerman wrote:
>>
>> Can you please ask for an ack before merging arch patches?
>>
>> That's a 70 line powerpc patch and a 6 line crypto patch. It has no
>> reviews and no acks. I would have preferred it if we could take it via
>> the powerpc tree.
>
> Sorry, I'll delete them from the crypto tree.
Thanks.
I'll assume patch 2 has your ack :)
cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported
From: Michael Ellerman @ 2016-07-19 9:13 UTC (permalink / raw)
To: Herbert Xu
Cc: alastair, linux-kernel, paulus, linux-crypto,
Alastair D'Silva, linuxppc-dev, davem
In-Reply-To: <20160719035939.GA20847@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Jul 19, 2016 at 11:01:55AM +1000, Michael Ellerman wrote:
>>
>> Can you please ask for an ack before merging arch patches?
>>
>> That's a 70 line powerpc patch and a 6 line crypto patch. It has no
>> reviews and no acks. I would have preferred it if we could take it via
>> the powerpc tree.
>
> Sorry, I'll delete them from the crypto tree.
Thanks.
I'll assume patch 2 has your ack :)
cheers
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/2] Automatically load the vmx_crypto module if supported
From: Herbert Xu @ 2016-07-19 9:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: alastair, benh, paulus, davem, linuxppc-dev, linux-crypto,
linux-kernel, Alastair D'Silva
In-Reply-To: <87poqa9eiz.fsf@@concordia.ellerman.id.au>
On Tue, Jul 19, 2016 at 07:13:24PM +1000, Michael Ellerman wrote:
>
> I'll assume patch 2 has your ack :)
Sure,
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
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
* [PATCH] crypto: vmx - Ignore generated files
From: Paulo Flabiano Smorigo @ 2016-07-19 13:36 UTC (permalink / raw)
To: linux-kernel
Cc: Paulo Flabiano Smorigo, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Herbert Xu, David S. Miller,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:CRYPTO API
Ignore assembly files generated by the perl script.
Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
---
drivers/crypto/vmx/.gitignore | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 drivers/crypto/vmx/.gitignore
diff --git a/drivers/crypto/vmx/.gitignore b/drivers/crypto/vmx/.gitignore
new file mode 100644
index 0000000..af4a7ce
--- /dev/null
+++ b/drivers/crypto/vmx/.gitignore
@@ -0,0 +1,2 @@
+aesp8-ppc.S
+ghashp8-ppc.S
--
2.5.5
^ permalink raw reply related
* Re: [Patch-V2 2/3] chcr: Support for Chelsio's Crypto Hardware
From: David Miller @ 2016-07-20 4:15 UTC (permalink / raw)
To: yeshaswi
Cc: hariprasad, netdev, linux-kernel, linux-crypto, jlulla, harsh,
atul.gupta, herbert
In-Reply-To: <1468906935-6770-3-git-send-email-yeshaswi@chelsio.com>
From: Yeshaswi M R Gowda <yeshaswi@chelsio.com>
Date: Mon, 18 Jul 2016 22:42:14 -0700
> +config CRYPTO_DEV_CHELSIO
> + tristate "Chelsio Crypto Co-processor Driver"
> + depends on PCI && NETDEVICES && ETHERNET
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + select CRYPTO_SHA512
> + select NET_VENDOR_CHELSIO
> + select CHELSIO_T4
The user shouldn't have to know about the technical details about
how this chip is physically implemented.
It's therefore not reasonable to require an ethernet driver to be
enabled to use the crypto engine.
Also, selecting Kconfig symbol X does not recursively enable the
"select" statement(s) of symbol X nor does it check symbol X's
dependencies.
This is really one big huge dependency mess, and I think you have
to split out the core of the T4 driver into a driver subtype
agnostic library or similar to make this work properly.
Don't just shoehorn this stuff into the ethernet driver. Round
peg, square hole.
^ permalink raw reply
* RE: [PATCH] crypto: vmx - Ignore generated files
From: David Laight @ 2016-07-20 13:15 UTC (permalink / raw)
To: 'Paulo Flabiano Smorigo', linux-kernel@vger.kernel.org
Cc: Herbert Xu, Paul Mackerras, open list:CRYPTO API,
open list:LINUX FOR POWERPC 32-BIT AND 64-BIT, David S. Miller
In-Reply-To: <1468935388-6489-1-git-send-email-pfsmorigo@linux.vnet.ibm.com>
From: Paulo Flabiano Smorigo
> Sent: 19 July 2016 14:36
> Ignore assembly files generated by the perl script.
...
> diff --git a/drivers/crypto/vmx/.gitignore b/drivers/crypto/vmx/.gitignore
> new file mode 100644
> index 0000000..af4a7ce
> --- /dev/null
> +++ b/drivers/crypto/vmx/.gitignore
> @@ -0,0 +1,2 @@
> +aesp8-ppc.S
> +ghashp8-ppc.S
Shouldn't the generated files be written to the object tree?
I would hope the linux kernel builds from a readonly source tree.
David
^ permalink raw reply
* Re: linux-next: build failure after merge of the crypto tree
From: Herbert Xu @ 2016-07-20 14:32 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Paulo Flabiano Smorigo,
Leonidas S. Barbosa, Linux Crypto Mailing List
In-Reply-To: <20160720174634.53bad636@canb.auug.org.au>
On Wed, Jul 20, 2016 at 05:46:34PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the dax-misc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/crypto/vmx/aesp8-ppc.S: Assembler messages:
> drivers/crypto/vmx/aesp8-ppc.S:2036: Error: symbol `.aes_p8_xts_decrypt' is already defined
>
> Caused by commit
>
> 11c6e16ee13a ("crypto: vmx - Adding asm subroutines for XTS")
>
> I have reverted that commit (and commit c07f5d3da643 ("crypto: vmx -
> Adding support for XTS")) for today.
Thanks Stephen. I think this patch should fix it.
---8<---
Subject: crypto: vmx - Fix aes_p8_xts_decrypt build failure
We use _GLOBAL so there is no need to do the manual alignment,
in fact it causes a build failure.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
index 813ffcc..0b4a293 100644
--- a/drivers/crypto/vmx/aesp8-ppc.pl
+++ b/drivers/crypto/vmx/aesp8-ppc.pl
@@ -2125,8 +2125,6 @@ Lxts_enc_ret:
.size .${prefix}_xts_encrypt,.-.${prefix}_xts_encrypt
.globl .${prefix}_xts_decrypt
-.align 5
-.${prefix}_xts_decrypt:
mr $inp,r3 # reassign
li r3,-1
${UCMP}i $len,16
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH] crypto: vmx - Ignore generated files
From: Herbert Xu @ 2016-07-20 14:44 UTC (permalink / raw)
To: Paulo Flabiano Smorigo
Cc: linux-kernel, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, David S. Miller,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT),
open list:CRYPTO API
In-Reply-To: <1468935388-6489-1-git-send-email-pfsmorigo@linux.vnet.ibm.com>
On Tue, Jul 19, 2016 at 10:36:26AM -0300, Paulo Flabiano Smorigo wrote:
> Ignore assembly files generated by the perl script.
>
> Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.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: qat - make qat_asym_algs.o depend on asn1 headers
From: Thomas Backlund @ 2016-07-20 15:37 UTC (permalink / raw)
To: Herbert Xu, Jan Stancek
Cc: tadeusz.struk, qat-linux, linux-crypto, linux-kernel,
Salvatore Benedetto
In-Reply-To: <20160701093008.GB13424@gondor.apana.org.au>
Den 01-07-2016 kl. 12:30, skrev Herbert Xu:
> On Thu, Jun 30, 2016 at 12:23:51PM +0200, Jan Stancek wrote:
>> Parallel build can sporadically fail because asn1 headers may
>> not be built yet by the time qat_asym_algs.o is compiled:
>> drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory
>> #include "qat_rsapubkey-asn1.h"
>>
>> Signed-off-by: Jan Stancek <jstancek@redhat.com>
>> Cc: Tadeusz Struk <tadeusz.struk@intel.com>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>
> Jan, Salvatore just posted a patch to delete the qat ASN code
> altogether, so your patch won't be needed.
>
> Thanks,
>
Yeah, but that patch seem to be heading to 4.8 only , so qat build in
upcoming 4.7 still breaks...
and pulling that fix only to 4.7 breaks too, so I guess more fixes
would be needed for proper backport then...
or are the qat fixes already queued somewhere for 4.7 final ?
--
Thomas
^ permalink raw reply
* Re: [PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers
From: Herbert Xu @ 2016-07-21 4:14 UTC (permalink / raw)
To: Thomas Backlund
Cc: Jan Stancek, tadeusz.struk, qat-linux, linux-crypto, linux-kernel,
Salvatore Benedetto
In-Reply-To: <75bc3619-1d11-4759-257c-d2db4ba442ff@mageia.org>
On Wed, Jul 20, 2016 at 06:37:07PM +0300, Thomas Backlund wrote:
>
> Yeah, but that patch seem to be heading to 4.8 only , so qat build
> in upcoming 4.7 still breaks...
>
> and pulling that fix only to 4.7 breaks too, so I guess more fixes
> would be needed for proper backport then...
>
> or are the qat fixes already queued somewhere for 4.7 final ?
You're right. This patch is probably the safest fix for 4.7.
I'll bounce it to stable.
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
* Max data limit for AEAD operation
From: Harsh Jain @ 2016-07-21 12:12 UTC (permalink / raw)
To: linux-crypto
Hi All,
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?
Regards
Harsh Jain
^ permalink raw reply
* [PATCH] crypto: x86/glue_helper make bool
From: Luis R. Rodriguez @ 2016-07-21 22:13 UTC (permalink / raw)
To: herbert, davem, paul.gortmaker
Cc: lkp, linux-crypto, linux-kernel, Luis R. Rodriguez
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.
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 related
* 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
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