Re: [v3 RFC PATCH 2/2] crypto: ecc: use caller's GFP flags

On Wed, Jun 28, 2017 at 05:08:36PM +0300, Tudor Ambarus wrote: > Using GFP_KERNEL when allocating data and implicitly > assuming that we can sleep was wrong because the caller > could be in atomic context. Let the caller decide whether > sleeping is possible or not. > > The caller (ecdh) was

Re: [v3 RFC PATCH 1/2] crypto: ecdh: fix concurrency on ecdh_ctx

On Wed, Jun 28, 2017 at 05:08:35PM +0300, Tudor Ambarus wrote: > ecdh_ctx contained static allocated data for the shared secret, > for the public and private key. > > When talking about shared secret and public key, they were > doomed to concurrency issues because they could be shared by >

Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

Hi Martin, On 18 July 2017 at 02:46, Martin Kaiser wrote: > From: Steffen Trumtrar > > The driver is ported from Freescales Linux git and can be > found in the > > vendor/freescale/imx_2.6.35_maintain > > branch. > > According to that code,

Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code

On Tue, Jun 27, 2017 at 05:26:13PM -0700, Megha Dey wrote: > > +static void completion_callback(struct mcryptd_skcipher_request_ctx *rctx, > + struct mcryptd_alg_cstate *cstate, > + int err) > +{ > + struct skcipher_request *req =

Re: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted

On Tue, Jun 20, 2017 at 11:28:53AM +0200, Ard Biesheuvel wrote: > The generic AES driver uses 16 lookup tables of 1 KB each, and has > encryption and decryption routines that are fully unrolled. Given how > the dependencies between this code and other drivers are declared in > Kconfig files, this

Re: [PATCH 1/3] staging: ccree: Replace kzalloc with devm_kzalloc

On Monday 17 July 2017 06:03 PM, Greg KH wrote: > On Sat, Jul 15, 2017 at 01:21:54PM +0530, suni...@techveda.org wrote: >> From: Suniel Mahesh >> >> It is recommended to use managed function devm_kzalloc, which >> simplifies driver cleanup paths and driver code. >> This

Re: [PATCH V6 0/7] crypto: AES CBC multibuffer implementation

Hi Herbert, Do you want any other changes to be made to this patchset? Thanks, Megha On Tue, 2017-06-27 at 17:26 -0700, Megha Dey wrote: > In this patch series, we introduce AES CBC encryption that is parallelized on > x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data >

[PATCH V2 6/6] crypto/nx: Add P9 NX support for 842 compression engine

This patch adds P9 NX support for 842 compression engine. Virtual Accelerator Switchboard (VAS) is used to access 842 engine on P9. For each NX engine per chip, setup receive window using vas_rx_win_open() which configures RxFIFo with FIFO address, lpid, pid and tid values. This unique (lpid,

[PATCH V2 5/6] crypto/nx: Add P9 NX specific error codes for 842 engine

This patch adds changes for checking P9 specific 842 engine error codes. These errros are reported in coprocessor status block (CSB) for failures. Signed-off-by: Haren Myneni --- arch/powerpc/include/asm/icswx.h | 3 +++ drivers/crypto/nx/nx-842-powernv.c | 18

[PATCH V2 4/6] crypto/nx: Add nx842_add_coprocs_list function

Updating coprocessor list is moved to nx842_add_coprocs_list(). This function will be used for both icswx and VAS functions. Signed-off-by: Haren Myneni --- drivers/crypto/nx/nx-842-powernv.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git

[PATCH V2 2/6] crypto/nx: Create nx842_configure_crb function

Configure CRB is moved to nx842_configure_crb() so that it can be used for icswx and VAS exec functions. VAS function will be added later with P9 support. Signed-off-by: Haren Myneni --- drivers/crypto/nx/nx-842-powernv.c | 57 +- 1 file

[PATCH V2 1/6] crypto/nx842: Rename nx842_powernv_function as icswx function

Rename nx842_powernv_function to nx842_powernv_exec. nx842_powernv_exec points to nx842_exec_icswx and will be point to VAS exec function which will be added later for P9 NX support. Signed-off-by: Haren Myneni --- drivers/crypto/nx/nx-842-powernv.c | 20 +---

[PATCH V2 0/6] Enable NX 842 compression engine on Power9

[PATCH V2 0/6] Enable NX 842 compression engine on Power9 P9 introduces Virtual Accelerator Switchboard (VAS) to communicate with NX 842 engine. icswx function is used to access NX before. On powerNV systems, NX-842 driver invokes VAS functions for configuring RxFIFO (receive window) per each NX

Re: [PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

On 7/17/2017 3:08 PM, Gary R Hook wrote: Version 5 CCPs have differing requirements for XTS-AES: key components are stored in a 512-bit vector. The context must be little-endian justified. AES-256 is supported now, so propagate the cipher size to the command descriptor. Signed-off-by: Gary R

Re: [PATCH v2 1/3] Documentation: devicetree: add Freescale RNGC binding

Hi, I'd like to pick this up and get the rngc driver merged finally. Thus wrote Rob Herring (r...@kernel.org): > The MXC name is still not dead? looks like no. There's still CONFIG_ARCH_MXC etc. The other similar rng driver is called mxc-rnga.c so it makes sense to use mxc-rngc. > > 1 file

Re: [PATCH v2 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

Dear all, looking for a Freescale RNGB/C driver, I came across this old mail thread. It seems the review got stuck and the driver was never merged. This mail is the latest conversation I could find. I would like to pick up this work and prepare the RNGC driver for merging into the mailine

Re: [PATCH v2 2/3] ARM: i.MX25: add RNGC node to dtsi

Dear all, I'd like to pick this up and get the rgnc driver merged. Thus wrote Shawn Guo (shawn...@kernel.org): > > + rng: rng@53fb { > > + compatible = "fsl,imx25-rng"; > > + reg = <0x53fb 0x4000>; > > +

[PATCH v3 2/3] ARM: i.MX25: add RNGC node to dtsi

From: Steffen Trumtrar Add a devicetree entry for the Random Number Generator Version C (RNGC). Signed-off-by: Steffen Trumtrar Signed-off-by: Martin Kaiser --- Changes in v3: - remove clock-names from dtsi Changes in

[PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

From: Steffen Trumtrar The driver is ported from Freescales Linux git and can be found in the vendor/freescale/imx_2.6.35_maintain branch. According to that code, the RNGC is found on Freescales i.MX3/5 SoCs. The i.MX2x actually has an RNGB, which has no

[PATCH v3 1/3] Documentation: devicetree: add Freescale RNGC binding

From: Steffen Trumtrar Add binding documentation for the Freescale RNGC found on some i.MX2/3 SoCs. Signed-off-by: Steffen Trumtrar Signed-off-by: Martin Kaiser --- Changes in v3: - add compatible string for imx35 -

[PATCH 4/4] csrypto: ccp - Expand RSA support for a v5 ccp

A version 5 CCP can handle an RSA modulus up to 16k bits. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/ccp-crypto-rsa.c |5 - drivers/crypto/ccp/ccp-crypto.h |1 + drivers/crypto/ccp/ccp-dev-v3.c |1 + drivers/crypto/ccp/ccp-dev-v5.c |2 ++

[PATCH 3/4] crypto: ccp - Add support for RSA on the CCP

Wire up the CCP as an RSA cipher provider. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/Makefile |1 drivers/crypto/ccp/ccp-crypto-main.c | 19 ++ drivers/crypto/ccp/ccp-crypto-rsa.c | 296 ++

[PATCH 1/4] crypto: ccp - Fix base RSA function for version 5 CCPs

Version 5 devices have requirements for buffer lengths, as well as parameter format (e.g. bits vs. bytes). Fix the base CCP driver code to meet requirements all supported versions. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/ccp-dev-v5.c | 10 +++--

[PATCH 2/4] crypto: Add akcipher_set_reqsize() function

Signed-off-by: Gary R Hook --- 0 files changed diff --git a/include/crypto/internal/akcipher.h b/include/crypto/internal/akcipher.h index 479a0078f0f7..805686ba2be4 100644 --- a/include/crypto/internal/akcipher.h +++ b/include/crypto/internal/akcipher.h @@ -38,6 +38,12 @@

[PATCH 0/4] Enable RSA Support on the CCP

This series accomplishes the following: - Fix RSA support in the base CCP driver - Add the akcipher_set_reqsize() function - Enable RSA support in the crypto layer - Allow for a larger RSA modulus in a version 5 CCP --- Gary R Hook (4): crypto: ccp - Fix base RSA function for version

[PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

Version 5 CCPs have differing requirements for XTS-AES: key components are stored in a 512-bit vector. The context must be little-endian justified. AES-256 is supported now, so propagate the cipher size to the command descriptor. Signed-off-by: Gary R Hook ---

[PATCH] crypto: ccp - Update copyright dates for 2017.

Some updates this year have not had copyright dates changed in modified files. Correct this for 2017. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/ccp-crypto-aes-galois.c |2 +- drivers/crypto/ccp/ccp-crypto-des3.c |2 +-

Re: [PATCH 1/2] dt-bindings: Document STM32 HASH bindings

On Thu, Jul 13, 2017 at 03:32:26PM +0200, Lionel Debieve wrote: > This adds documentation of device tree bindings for the STM32 > HASH controller. > > Signed-off-by: Lionel Debieve > --- > .../devicetree/bindings/crypto/st,stm32-hash.txt | 30 > ++ >

Re: KPP questions and confusion

Hi Kyle, > I am confused about several things in the new key agreement code. > > net/bluetooth/smp.c in two places generates random bytes for the > private_key argument to > net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests the > private key is static within the function. However,

Re: [PATCH 6/6] fscrypt: for v2 policies, support "fscrypt:" key prefix only

On Wed, Jul 12, 2017 at 02:00:35PM -0700, Eric Biggers wrote: > From: Eric Biggers > > Since v2 encryption policies are opt-in, take the opportunity to also > drop support for the legacy filesystem-specific key description prefixes > "ext4:", "f2fs:", and "ubifs:", instead

Re: [PATCH 2/3] dt-bindings: Document STM32 CRYP bindings

On Thu, Jul 13, 2017 at 11:59:38AM +0200, Fabien Dessenne wrote: > Document device tree bindings for the STM32 CRYP. > > Signed-off-by: Fabien Dessenne > --- > .../devicetree/bindings/crypto/st,stm32-cryp.txt | 20 > > 1 file changed, 20

Re: [PATCH 5/6] fscrypt: cache the HMAC transform for each master key

On Wed, Jul 12, 2017 at 02:00:34PM -0700, Eric Biggers wrote: > From: Eric Biggers > > Now that we have a key_hash field which securely identifies a master key > payload, introduce a cache of the HMAC transforms for the master keys > currently in use for inodes using v2+

Re: [RESEND,PATCH v4 3/3] crypto : stm32 - Add STM32F4 CRC32 support

On Mon, Jul 17, 2017 at 02:23:44PM +, Lionel DEBIEVE wrote: > Hi Cosar, > > - ret = crypto_register_shashes(algs, ARRAY_SIZE(algs)); > + /* For F4 series only CRC32 algorithm will be used */ > + if (of_device_is_compatible(crc->dev->of_node, "st,stm32f4-crc")) > +

KPP questions and confusion

I am confused about several things in the new key agreement code. net/bluetooth/smp.c in two places generates random bytes for the private_key argument to net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests the private key is static within the function. However, there is a do ...

Re: [RESEND,PATCH v4 3/3] crypto : stm32 - Add STM32F4 CRC32 support

Hi Cosar, - ret = crypto_register_shashes(algs, ARRAY_SIZE(algs)); + /* For F4 series only CRC32 algorithm will be used */ + if (of_device_is_compatible(crc->dev->of_node, "st,stm32f4-crc")) + algs_size = 1; + else + algs_size =

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

Hi Herbert: Ping... any comments for this patch? Regards Xin < -Original Message- < From: Zeng, Xin < Sent: Friday, June 23, 2017 11:31 PM < To: herb...@gondor.apana.org.au; virtio-...@lists.oasis-open.org < Cc: linux-crypto@vger.kernel.org; arei.gong...@huawei.com; Zeng, Xin <

[PATCH] drivers: staging: ccree: use __func__ to get function name in error messages.

fixes checkpatch warning. Signed-off-by: Dhananjay Balan --- drivers/staging/ccree/ssi_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/ccree/ssi_driver.c b/drivers/staging/ccree/ssi_driver.c index d7b9a636d907..e0faca0a30a6 100644

Re: [PATCH 1/3] staging: ccree: Replace kzalloc with devm_kzalloc

On Sat, Jul 15, 2017 at 01:21:54PM +0530, suni...@techveda.org wrote: > From: Suniel Mahesh > > It is recommended to use managed function devm_kzalloc, which > simplifies driver cleanup paths and driver code. > This patch does the following: > (a) replace kzalloc with

[PATCH 1/2] crypto: inside-secure - fix invalidation check in hmac_sha1_setkey

The safexcel_hmac_sha1_setkey function checks if an invalidation command should be issued, i.e. when the context ipad/opad change. This checks is done after filling the ipad/opad which and it can't be true. The patch fixes this by moving the check before the ipad/opad memcpy operations.

[PATCH 2/2] crypto: inside-secure - fix the sha state length in hmac_sha1_setkey

A check is performed on the ipad/opad in the safexcel_hmac_sha1_setkey function, but the index used by the loop doing it is wrong. It is currently the size of the state array while it should be the size of a sha1 state. This patch fixes it. Reported-by: Dan Carpenter

[RESEND,PATCH v4 3/3] crypto : stm32 - Add STM32F4 CRC32 support

This patch adds CRC (CRC32 Crypto) support for STM32F4 series. As an hardware limitation polynomial and key setting are not supported. They are fixed as 0x4C11DB7 (poly) and 0x (key). CRC32C Castagnoli algorithm is not used. Signed-off-by: Cosar Dindar

[RESEND,PATCH v4 2/3] dt-bindings : Document the STM32F4 CRC32 binding

Add device tree binding for STM32F4. Signed-off-by: Cosar Dindar --- Documentation/devicetree/bindings/crypto/st,stm32-crc.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt

[RESEND,PATCH v4 0/2] Add support for the STM32F4 CRC32

This patch series add hardware CRC32 ("Ethernet") calculation support for STMicroelectronics STM32F429. Polynomial and key setting are not supported, key is fixed as 0x4C11DB7 and poly is 0x. Module is tested on STM32F429-disco board with crypto testmgr using cases within the key

[PATCH] crypto: authencesn - Fix digest_null crash

When authencesn is used together with digest_null a crash will occur on the decrypt path. This is because normally we perform a special setup to preserve the ESN, but this is skipped if there is no authentication. However, on the post-authentication path it always expects the preservation to be