Re: [PATCH 3/7] staging: ccree: add support for older HW revisions

Hi Gilad, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20170623] [cannot apply to v4.12-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Gilad-Ben

RE: [bug] sha1-avx2 and read beyond

Hello all, I'm sorry for late reply (I was out of office for a month). It's been a while since we touched this code. We are going to do our best to support it. I'll be back to the office earlier next week and will figure out the fix ASAP. Best Regards, Ilya Albrekht -Original

Re: [PATCH 0/3] Introduce AMD Secure Processor device

On 06/22/2017 08:25 AM, Pavel Machek wrote: On Thu 2017-06-22 06:42:01, Brijesh Singh wrote: CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices.

Re: [PATCH v2 3/7] staging: ccree: add support for older HW revisions

On Thu, Jun 22, 2017 at 04:36:57PM +0300, Gilad Ben-Yossef wrote: > Add support for the older CryptoCell 710 and 630P hardware revisions. No, I do not want to add new features to staging drivers where ever possible. I want you to spend your time fixing up the code to be good enough to get it out

Re: [PATCH v2 5/7] staging: ccree: add clock management support

On Thu, Jun 22, 2017 at 04:36:59PM +0300, Gilad Ben-Yossef wrote: > Some SoC which implement CryptoCell have a dedicated clock > tied to it, some do not. Implement clock support if exists > based on device tree data and tie power management to it. > > Signed-off-by: Gilad Ben-Yossef

Re: [PATCH v2 2/7] staging: ccree: register setkey for none hash macs

On Thu, Jun 22, 2017 at 04:36:56PM +0300, Gilad Ben-Yossef wrote: > Fix a bug where the transformation init code did > not register a setkey method for none hash based MACs. "none hash based MACs"? Is that the correct language, I don't understand it, sorry, can you expand on it a bit in your v3

Re: [PATCH 0/3] Introduce AMD Secure Processor device

On Thu 2017-06-22 06:42:01, Brijesh Singh wrote: > CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, > which is not dedicated solely to crypto. The AMD Secure Processor includes > CCP and PSP (Platform Secure Processor) devices. > > This patch series adds a framework that

Re: Regarding Porting of hardware cryptography to Linux kernel

On 06/23/2017 07:16 AM, sagar khadgi wrote: > Hi Marek, Hi, > Thanks for replying. > > Regarding Hardware: > > I am using Xilinx zynq FPGA with Athena Core which as AES, RSA, DSA, > ECDSA, NRBG etc feature. > I am trying to integrate with Linux kernal. Can you please tell me is > there any

Re: [PATCH v6 0/2] IV Generation algorithms for dm-crypt

On Fri, Jun 23, 2017 at 04:13:41PM +0800, Herbert Xu wrote: > Binoy Jayan wrote: > > === > > dm-crypt optimization for larger block sizes > >

Re: [PATCH 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Thanks Horia. I'm inclined to just use your patch verbatim. I can set you as author, but no matter how I do it, I'll need your Signed-off-by. Logan On 23/06/17 12:51 AM, Horia Geantă wrote: > On 6/22/2017 7:49 PM, Logan Gunthorpe wrote: >> Now that ioread64 and iowrite64 are always available we

Re: [PATCH v1] crypto: brcm - software fallback for cryptlen zero

Need to consider some more scenarios. So NAKing this patch. Will send out re-vised version. Regards, Raveendra On Fri, Jun 23, 2017 at 2:24 PM, Raveendra Padasalagi wrote: > Zero length payload requests are not handled in > Broadcom SPU2 engine, so this patch

Re: [bug] sha1-avx2 and read beyond

On 06/23/2017 01:48 AM, Jan Stancek wrote: > > > - Original Message - >> On Wed, May 24, 2017 at 08:46:57AM -0400, Jan Stancek wrote: >>> >>> >>> - Original Message - Hi, I'm seeing rare crashes during NFS cthon with krb5 auth. After some digging I arrived at

[PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

Update pci and platform files to use devres interface to allocate the PCI and iomap resources. Also add helper functions to consolicate module init, exit and power mangagement code duplication. Signed-off-by: Brijesh Singh --- drivers/crypto/ccp/ccp-dev-v3.c | 8 +++

[PATCH v2 3/3] crypto: cpp - Abstract interrupt registeration

The CCP and PSP devices part of AMD Secure Procesor may share the same interrupt. Hence we expand the SP device to register a common interrupt handler and provide functions to CCP and PSP devices to register their interrupt callback which will be invoked upon interrupt. Signed-off-by: Brijesh

[PATCH v2 0/3] Introduce AMD Secure Processor device

CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor, which is not dedicated solely to crypto. The AMD Secure Processor includes CCP and PSP (Platform Secure Processor) devices. This patch series adds a framework that allows functional component of the AMD Secure Processor to be

[PATCH v2 2/3] crypto: ccp - Introduce the AMD Secure Processor device

The CCP device is part of the AMD Secure Processor. In order to expand the usage of the AMD Secure Processor, create a framework that allows functional components of the AMD Secure Processor to be initialized and handled appropriately. Signed-off-by: Brijesh Singh ---

[PATCH] crypto: virtio - Refacotor virtio_crypto driver for new virito crypto services

In current virtio crypto device driver, some common data structures and implementations that should be used by other virtio crypto algorithms (e.g. asymmetric crypto algorithms) introduce symmetric crypto algorithms specific implementations. This patch refactors these pieces of code so that they

Re: [PATCH] Documentation/bindings: crypto: remove the dma-mask property

On Fri, Jun 23, 2017 at 4:52 PM, Antoine Tenart wrote: > The dma-mask property is broken and was removed in the device trees > having a safexcel-eip197 node and in the safexcel cryptographic > driver. This patch removes the dma-mask property from the

[PATCH] Documentation/bindings: crypto: remove the dma-mask property

The dma-mask property is broken and was removed in the device trees having a safexcel-eip197 node and in the safexcel cryptographic driver. This patch removes the dma-mask property from the documentation as well. Signed-off-by: Antoine Tenart ---

Re: [PATCH] crypto: inside-secure - do not parse the dma mask from dt

On Fri, Jun 23, 2017 at 4:05 PM, Antoine Tenart wrote: > Remove the dma mask parsing from dt as this should not be encoded into > the engine device tree node. Keep the fallback value for now, which > should work for the boards already supported upstream. > >

[PATCH] crypto: chcr: Avoid algo allocation in softirq.

Thsi patch fixes calling "crypto_alloc_cipher" call in bottom halves. Pre allocate aes cipher required to update Tweak value for XTS. Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 23 +++ drivers/crypto/chelsio/chcr_crypto.h | 1 +

[PATCH] crypto: inside-secure - do not parse the dma mask from dt

Remove the dma mask parsing from dt as this should not be encoded into the engine device tree node. Keep the fallback value for now, which should work for the boards already supported upstream. Signed-off-by: Antoine Tenart --- Hi Herbert, As pointed our by

[RFC PATCH linux-next] crypto: cvm_encrypt() can be static

Signed-off-by: Fengguang Wu --- cptvf_algs.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/cavium/cpt/cptvf_algs.c b/drivers/crypto/cavium/cpt/cptvf_algs.c index 443c362..4303674 100644 ---

[linux-next:master 7715/9581] drivers/crypto/cavium/cpt/cptvf_algs.c:225:5: sparse: symbol 'cvm_encrypt' was not declared. Should it be static?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: a73468728fd8f34ccbd7c60f0808024ae491f4d6 commit: e2eb769ed0bdc06cb523f475db411ce3a5f1c465 [7715/9581] crypto: cavium - Remove the individual encrypt/decrypt function for each algorithm reproduce: #

[PATCH][crypto-next] crypto: cavium/nitrox - Change in firmware path.

Moved the firmware to "cavium" subdirectory as suggested by Kyle McMartin. Signed-off-by: Srikanth Jampala --- drivers/crypto/cavium/nitrox/nitrox_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/cavium/nitrox/nitrox_main.c

Re: [PATCH 1/1] cavium: Add firmware for CNN55XX crypto driver.

Sure kyle, I will work on this. Thanks. On Friday 23 June 2017 12:39 AM, Kyle McMartin wrote: > On Fri, Jun 16, 2017 at 07:52:26PM +0530, Srikanth Jampala wrote: >> This patchset adds the firmware for CNN55XX cryto driver, >> supports Symmetric crypto operations. >> >> The version of the

Re: [PATCH v10 1/2] crypto: skcipher AF_ALG - overhaul memory management

Am Freitag, 23. Juni 2017, 08:10:48 CEST schrieb Herbert Xu: Hi Herbert, > On Wed, Jun 21, 2017 at 10:03:02PM +0200, Stephan Müller wrote: > > + /* convert iovecs of output buffers into RX SGL */ > > + while (len < ctx->used && msg_data_left(msg)) { > > How are we supposed to reach the wait

[PATCH v1] crypto: brcm - Fix SHA3-512 algorithm failure

In Broadcom SPU driver, due to missing break statement in spu2_hash_xlate() while mapping SPU2 equivalent SHA3-512 value, -EINVAL is chosen and hence leading to failure of SHA3-512 algorithm. This patch fixes the same. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by:

[PATCH v1] crypto: brcm - software fallback for cryptlen zero

Zero length payload requests are not handled in Broadcom SPU2 engine, so this patch adds conditional check to fallback to software implementation for AES-GCM and AES-CCM algorithms. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by: Raveendra Padasalagi

Re: [bug] sha1-avx2 and read beyond

On Fri, Jun 23, 2017 at 04:48:51AM -0400, Jan Stancek wrote: > > So I take it my workaround patch [1] is not acceptable in > short-term as well? > > [1] http://marc.info/?l=linux-crypto-vger=149373371023377 As we don't have a proper fix we may not be aware of the complete scope of the problem

Re: dm-crypt IV generation (summary)

On Thu, May 18, 2017 at 01:40:38PM +0200, Ondrej Mosnacek wrote: > > > Actually I think this one can probably easily handled in the crypto > > layer. All we need is to add a multikey template that sits on top > > of an underlying IV generator. The multikey instance can then accept > > a key

Re: [bug] sha1-avx2 and read beyond

- Original Message - > On Wed, May 24, 2017 at 08:46:57AM -0400, Jan Stancek wrote: > > > > > > - Original Message - > > > Hi, > > > > > > I'm seeing rare crashes during NFS cthon with krb5 auth. After > > > some digging I arrived at potential problem with sha1-avx2. > > > >

Re: [bug] sha1-avx2 and read beyond

On Wed, May 24, 2017 at 08:46:57AM -0400, Jan Stancek wrote: > > > - Original Message - > > Hi, > > > > I'm seeing rare crashes during NFS cthon with krb5 auth. After > > some digging I arrived at potential problem with sha1-avx2. > > Adding more sha1_avx2 experts to CC. > > > > >

Re: encrypt_done called from interrupt context on rk3288 crypto driver

On Thu, May 25, 2017 at 10:38:13PM +0300, Emil Karlson wrote: > Greetings > > It seems to me that rk3288 crypto driver calls encrypt_done from > interrupt context which causes runtime tests to fail. Zain, can you please take a look at this? It is illegal to call the completion function from

Re: [PATCH] crypto: brcm - software fallback for cryptlen zero

On Fri, Jun 23, 2017 at 1:52 PM, Raveendra Padasalagi wrote: > Zero length payload requests are not handled in > Broadcom SPU2 engine, so this patch adds conditional > check to fallback to software implementation for AES-GCM > and AES-CCM algorithms. > >

Re: [PATCH] crypto: brcm - Fix SHA3-512 algorithm failure

On Fri, Jun 23, 2017 at 12:15 PM, Raveendra Padasalagi wrote: > In Broadcom SPU driver, due to missing break statement > in spu2_hash_xlate() while mapping SPU2 equivalent > SHA3-512 value, -EINVAL is chosen and hence leading to > failure of SHA3-512 algorithm.

Re: [Patch V5 1/7] crypto: Multi-buffer encryption infrastructure support

On Thu, Jun 08, 2017 at 12:52:54PM -0700, Megha Dey wrote: > > I will move this code to the mcryptd.c. > > About the naming scheme, could you give me an example where the internal > and external algorithm have the same name? I tried searching but did not > find any. > > When the outer and inner

[PATCH] crypto: brcm - software fallback for cryptlen zero

Zero length payload requests are not handled in Broadcom SPU2 engine, so this patch adds conditional check to fallback to software implementation for AES-GCM and AES-CCM algorithms. Signed-off-by: Raveendra Padasalagi Reviewed-by: Ray Jui

Re: [PATCH v6 0/2] IV Generation algorithms for dm-crypt

Binoy Jayan wrote: > === > dm-crypt optimization for larger block sizes > === > > Currently, the iv generation

Re: [PATCH 3/7] staging: ccree: add support for older HW revisions

-Yossef/staging-ccree-bug-fixes-and-TODO-items-for-4-13/20170623-134445 config: sparc64-allmodconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin

Re: [RFC PATCH] gcm - fix setkey cache coherence issues

On Fri, Jun 23, 2017 at 07:33:20AM +, Radu Solea wrote: > > Normally I would agree with you, if it's a weird requirement coming > from hardware or driver. In this case I think it's different. This is > not a limitation coming from one driver or one particular hardware > variety. It applies to

Re: [RFC PATCH] gcm - fix setkey cache coherence issues

On Vi, 2017-06-23 at 14:31 +0800, Herbert Xu wrote: > > The crypto API cannot rely on users providing aligned buffers.  So > if your driver has an alignment requirement, it either has to use > the existing crypto API alignmask setting which can cope with some > unaligned inputs, e.g., the IV if

Re: [PATCH 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

On 6/22/2017 7:49 PM, Logan Gunthorpe wrote: > Now that ioread64 and iowrite64 are always available we don't > need the ugly ifdefs to change their implementation when they > are not. > Thanks Logan. Note however this is not equivalent - it changes the behaviour, since CAAM engine on

Re: [PATCH v2 2/2] crypto: engine - Permit to enqueue skcipher request

On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote: > > Since there are two different user of "crypto engine + ablkcipher", it will > be not easy to convert them in one serie. (I could do it, but I simply could > not test it for OMAP (lack of hw)) > And any new user which want to use

[PATCH] crypto: brcm - Fix SHA3-512 algorithm failure

In Broadcom SPU driver, due to missing break statement in spu2_hash_xlate() while mapping SPU2 equivalent SHA3-512 value, -EINVAL is chosen and hence leading to failure of SHA3-512 algorithm. This patch fixes the same. Signed-off-by: Raveendra Padasalagi

Re: [RFC PATCH] gcm - fix setkey cache coherence issues

On Thu, Jun 22, 2017 at 01:56:40PM +, Radu Solea wrote: > There are two ways of fixing this AFAIK: the first is adding > cacheline_aligned so those fields don't fall into the same cacheline. > The second is to kzalloc hash and iv separately. kmalloc should honor > ARCH_DMA_MINALIGN which would

Re: [PATCH v10 1/2] crypto: skcipher AF_ALG - overhaul memory management

On Wed, Jun 21, 2017 at 10:03:02PM +0200, Stephan Müller wrote: > > + /* convert iovecs of output buffers into RX SGL */ > + while (len < ctx->used && msg_data_left(msg)) { How are we supposed to reach the wait path when ctx->used == 0? > + /* > + * This error