Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

Mimi Zohar writes: > On Wed, 2017-08-02 at 18:52 -0400, Mimi Zohar wrote: >> On Wed, 2017-08-02 at 14:42 -0300, Thiago Jung Bauermann wrote: >> > Mimi Zohar writes: > >> > >> @@ -229,8 +251,24 @@ int ima_appraise_measurement(enum ima_hooks

[PATCH v6 0/7] make io{read|write}64 globally usable

Changes since v5: - Added a fix to the tilcdc driver to ensure it doesn't use the non-atomic operation. (This includes adding io{read|write}64[be]_is_nonatomic defines). Changes since v4: - Add functions so the powerpc implementation of iomap.c compiles. (As noticed by Horia) Changes since

[PATCH v6 6/7] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Acked-by: Dave Jiang Acked-by: Allen Hubbe

[PATCH v6 3/7] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

[PATCH v6 1/7] drm/tilcdc: ensure nonatomic iowrite64 is not used

Add a check to ensure iowrite64 is only used if it is atomic. It was decided in [1] that the tilcdc driver should not be using an atomic operation (so it was left out of this patchset). However, it turns out that through the drm code, a nonatomic header is actually included:

[PATCH v6 5/7] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

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

From: Horia Geantă We can now make use of the io-64-nonatomic-lo-hi header to always provide 64 bit IO operations. So this patch cleans up the extra CONFIG_64BIT ifdefs. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device

[PATCH v6 2/7] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-By:

[PATCH v6 4/7] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

Re: [PATCH v2 1/4] dt-bindings: crypto: add ARTPEC crypto

On Mon, Jul 24, 2017 at 09:07:29AM +0200, Lars Persson wrote: > Document the device tree bindings for the ARTPEC crypto accelerator on > ARTPEC-6 and ARTPEC-7 SoCs. > > Signed-off-by: Lars Persson > --- > .../devicetree/bindings/crypto/artpec6-crypto.txt| 16 >

Re: [PATCH v3 7/7] ima: Support module-style appended signatures for appraisal

On Wed, 2017-08-02 at 18:52 -0400, Mimi Zohar wrote: > On Wed, 2017-08-02 at 14:42 -0300, Thiago Jung Bauermann wrote: > > Mimi Zohar writes: > > >> @@ -229,8 +251,24 @@ int ima_appraise_measurement(enum ima_hooks func, > > >> goto out; > > >>

Re: [PATCH V2] staging: ccree: Fix format/argument mismatches

On Thu, 2017-08-03 at 17:09 +0800, kbuild test robot wrote: > Hi Joe, > > [auto build test WARNING on staging/staging-testing] > [also build test WARNING on next-20170803] > [cannot apply to v4.13-rc3] > [if your patch is applied to the wrong git tree, please drop us a note

[PATCH] crypto: sahara - Remove leftover from previous used spinlock

This driver previously used a spinlock. The spinlock is not used any more, but the spinlock variable was still there and also being initialized. Signed-off-by: Mogens Lauridsen --- drivers/crypto/sahara.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH v5] 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 --- Changes

[PATCH] crypto: sahara - Fix dma unmap direction

The direction used in dma_unmap_sg in aes calc is wrong. This result in the cache not being invalidated correct when aes calculation is done and result has been dma'ed to memory. This is seen as sporadic wrong result from aes calc. Signed-off-by: Mogens Lauridsen ---

Re: [PATCH resend 00/18] crypto: ARM/arm64 roundup for v4.14

On Thu, Aug 03, 2017 at 02:26:53PM +0800, Herbert Xu wrote: > On Mon, Jul 24, 2017 at 11:28:02AM +0100, Ard Biesheuvel wrote: > > This is a resend of all the patches I sent out recently that I would > > like to be considered for v4.14. Their main purpose is to prepare the > > arm64 crypto code to

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

On Thu, Aug 03, 2017 at 07:53:16PM +1000, Michael Ellerman wrote: > Herbert Xu writes: > > > On Fri, Jul 21, 2017 at 09:57:39PM -0700, Haren Myneni wrote: > >> > >> Configure CRB is moved to nx842_configure_crb() so that it can > >> be used for icswx and VAS exec

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

Herbert Xu writes: > On Fri, Jul 21, 2017 at 09:57:39PM -0700, Haren Myneni wrote: >> >> 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. >> >>

Re: [PATCH v1] crypto: caam - set hwrng quality level

On 03.08.2017 09:48, Horia Geantă wrote: On 8/3/2017 6:17 AM, Herbert Xu wrote: On Wed, Aug 02, 2017 at 02:03:14PM +, Horia Geantă wrote: Take CAAM's engine HWRNG: it can work both as a TRNG and as a TRNG-seeded DRBG (that's how it's currently configured). IIUC, both setups are fit as

Re: [PATCH V2] staging: ccree: Fix format/argument mismatches

Hi Joe, [auto build test WARNING on staging/staging-testing] [also build test WARNING on next-20170803] [cannot apply to v4.13-rc3] [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/Joe-Perches

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

On Thu, Aug 03, 2017 at 01:44:23PM +0800, Herbert Xu wrote: > On Mon, Jul 17, 2017 at 11:27:36AM +0300, Cosar Dindar wrote: > > 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

Re: KPP questions and confusion

Hi Tudor, >>> 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

Re: [PATCH 0/4] crypto: caam - add Job Ring support for DPAA2 parts

On 7/25/2017 4:50 PM, Shawn Guo wrote: > On Tue, Jul 25, 2017 at 01:31:52PM +, Horia Geantă wrote: >> On 7/25/2017 4:22 PM, Shawn Guo wrote: >>> On Tue, Jul 18, 2017 at 06:30:46PM +0300, Horia Geantă wrote: This patch set adds support for CAAM's legacy Job Ring backend / interface on

Re: [PATCH v1] crypto: caam - set hwrng quality level

On 8/3/2017 6:17 AM, Herbert Xu wrote: > On Wed, Aug 02, 2017 at 02:03:14PM +, Horia Geantă wrote: >> >> Take CAAM's engine HWRNG: it can work both as a TRNG and as a >> TRNG-seeded DRBG (that's how it's currently configured). >> IIUC, both setups are fit as source for the entropy pool. > >

Re: [PATCH v2 2/4] crypto: add crypto_(un)register_ahashes()

On Mon, Jul 24, 2017 at 09:07:30AM +0200, Lars Persson wrote: > From: Rabin Vincent > > There are already helpers to (un)register multiple normal > and AEAD algos. Add one for ahashes too. > > Signed-off-by: Lars Persson Patch applied. Thanks. -- Email:

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

On Sun, Jul 23, 2017 at 07:49:04PM +0200, Martin Kaiser wrote: > 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

Re: [RESEND PATCH 0/2] crypto/rockchip: fix some issue which causes crypto failed

On Mon, Jul 24, 2017 at 09:23:12AM +0800, zain wang wrote: > These patches fix some bugs on rockchip's crypto which would cause crypto > failed. > > zain wang (2): > crypto: rockchip - move the crypto completion from interrupt context > crypto: rockchip - return the err code when unable

Re: [PATCH v3 0/3] Update support for XTS-AES on AMD CCPs

On Tue, Jul 25, 2017 at 02:21:12PM -0500, Gary R Hook wrote: > The following series adds support for XS-AES on version 5 CCPs, both > 128- and 256-bit, and enhances/clarifies/simplifies some crypto layer > code. > > Changes since v2: > - Move a CCP v5 fix out of this patch series and submit

Re: [PATCH v2 3/4] crypto: axis: add ARTPEC-6/7 crypto accelerator driver

On Mon, Jul 24, 2017 at 09:07:31AM +0200, Lars Persson wrote: > This is an asynchronous crypto API driver for the accelerator present > in the ARTPEC-6 and -7 SoCs from Axis Communications AB. > > The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash > standards. > >

Re: [PATCH] crypto: ccp - Fix XTS-AES-128 support on v5 CCPs

On Tue, Jul 25, 2017 at 02:12:11PM -0500, Gary R Hook wrote: > Version 5 CCPs have some new requirements for XTS-AES: the type field > must be specified, and the key requires 512 bits, with each part > occupying 256 bits and padded with zeroes. > > cc: # 4.9.x+ > >

Re: [PATCH resend 00/18] crypto: ARM/arm64 roundup for v4.14

On Mon, Jul 24, 2017 at 11:28:02AM +0100, Ard Biesheuvel wrote: > This is a resend of all the patches I sent out recently that I would > like to be considered for v4.14. Their main purpose is to prepare the > arm64 crypto code to deal with situations where the SIMD register file > is unavailable,

Re: [PATCH v2 4/4] MAINTAINERS: Add ARTPEC crypto maintainer

On Mon, Jul 24, 2017 at 09:07:32AM +0200, Lars Persson wrote: > Assign the Axis kernel team as maintainer for crypto drivers under > drivers/crypto/axis. > > Signed-off-by: Lars Persson Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v6 3/3] hwrng: add a driver for Freescale RNGC

On Sun, Jul 23, 2017 at 07:49:06PM +0200, Martin Kaiser wrote: > The driver is ported from Freescale's Linux git and can be > found in the > > vendor/freescale/imx_2.6.35_maintain > > branch. > > The driver supports both RNG version C that's part of some Freescale > i.MX3 SoCs and version

Re: [PATCH] crypto: Kconfig: Correct help text about feeding entropy pool

PrasannaKumar Muralidharan wrote: > Modify Kconfig help text to reflect the fact that random data from hwrng > is fed into kernel random number generator's entropy pool. > > Signed-off-by: PrasannaKumar Muralidharan Patch applied.

Re: [PATCH v2 0/3] crypto: scompress - defer allocation of percpu scratch buffers

On Fri, Jul 21, 2017 at 04:42:35PM +0100, Ard Biesheuvel wrote: > This is a followup to 'crypto: scompress - eliminate percpu scratch buffers', > which attempted to replace the scompress per-CPU buffer entirely, but as > Herbert pointed out, this is not going to fly in the targeted use cases. > >

Re: [PATCH v1] crypto: brcm - Support more FlexRM rings than SPU engines.

On Fri, Jul 21, 2017 at 11:17:39AM +0530, Raveendra Padasalagi wrote: > Enhance code to generically support cases where DMA rings > are greater than or equal to number of SPU engines. > New hardware has underlying DMA engine-FlexRM with 32 rings > which can be used to communicate to any of the

Re: [PATCH] crypto: atmel-ecc: fix signed integer to u8 assignment

On Thu, Jul 20, 2017 at 04:35:49PM +0300, Tudor Ambarus wrote: > static checker warning: > drivers/crypto/atmel-ecc.c:281 atmel_ecdh_done() > warn: assigning (-22) to unsigned variable 'status' > > Similar warning can be raised in atmel_ecc_work_handler() > when

Re: [PATCH] crypto: ccp: remove duplicate module version and author entry

On Wed, Jul 19, 2017 at 10:29:08PM -0500, Brijesh Singh wrote: > commit 720419f01832 ("crypto: ccp - Introduce the AMD Secure Processor > device") > moved the module registeration from ccp-dev.c to sp-dev.c but patch missed > removing the module version and author entry from ccp-dev.c. > > It

Re: [PATCH] crypto: tcrypt - remove AES-XTS-192 speed tests

On Wed, Jul 19, 2017 at 07:40:32PM +0300, Horia Geantă wrote: > Remove xts(aes) speed tests with 2 x 192-bit keys, since implementations > adhering strictly to IEEE 1619-2007 standard cannot cope with key sizes > other than 2 x 128, 2 x 256 bits - i.e. AES-XTS-{128,256}: > [...] > tcrypt: test 5

Re: [PATCH] crypto: ecdh: fix concurrency on shared secret and pubkey

On Thu, Jul 20, 2017 at 10:37:39AM +0300, Tudor Ambarus wrote: > ecdh_ctx contained static allocated data for the shared secret > and public key. > > The shared secret and the public key were doomed to concurrency > issues because they could be shared by multiple crypto requests. > > The

Re: [PATCH] Crypto: atmel-ecc: Make a couple of local functions static

On Wed, Jul 19, 2017 at 10:24:15AM +0100, Colin King wrote: > From: Colin Ian King > > Functions atmel_ecc_i2c_client_alloc and atmel_ecc_i2c_client_free are > local to the source and no not need to be in the global scope. Make > them static. > > Cleans up sparse

Re: [PATCH] crypto: atmel-tdes: remove unnecessary static in atmel_tdes_remove()

Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable tdes_dd. Such variable > is initialized before being used, on every execution path throughout > the function. The static has no benefit and, removing it reduces the > object file size. > > This issue

Re: [PATCH] crypto: atmel-sha: remove unnecessary static in atmel_sha_remove()

Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable sha_dd. Such variable > is initialized before being used, on every execution path throughout > the function. The static has no benefit and, removing it reduces the > object file size. > > This issue

Re: [PATCH] crypto: img-hash: remove unnecessary static in img_hash_remove()

Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable hdev. Such variable > is initialized before being used, on every execution path throughout > the function. The static has no benefit and, removing it reduces the > object file size. > > This issue

Re: [PATCH] crypto: omap-sham: remove unnecessary static in omap_sham_remove()

Gustavo A. R. Silva wrote: > Remove unnecessary static on local variable dd. Such variable > is initialized before being used, on every execution path throughout > the function. The static has no benefit and, removing it reduces the > object file size. > > This issue was

Re: [PATCH] crypto: n2_core: Convert to using %pOF instead of full_name

On Tue, Jul 18, 2017 at 04:42:56PM -0500, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc:

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

On Wed, Jul 19, 2017 at 11:02:31AM +0200, Antoine Tenart wrote: > 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

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

On Wed, Jul 19, 2017 at 11:02:30AM +0200, Antoine Tenart wrote: > 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

Re: [PATCH 1/4] crypto: caam/jr - add support for DPAA2 parts

On Tue, Jul 18, 2017 at 06:30:47PM +0300, Horia Geantă wrote: > Add support for using the caam/jr backend on DPAA2-based SoCs. > These have some particularities we have to account for: > -HW S/G format is different > -Management Complex (MC) firmware initializes / manages (partially) > the CAAM