Re: [PATCH v1 1/5] crypto: ccp: Fix command completion detection race

On 07/03/2018 12:11 PM, Tom Lendacky wrote: The wait_event() function is used to detect command completion. The interrupt handler will set the wait condition variable when the interrupt is triggered. However, the variable used for wait_event() is initialized after the command has been

Re: [PATCH v1 1/5] crypto: ccp: Fix command completion detection race

On 07/03/2018 12:11 PM, Tom Lendacky wrote: The wait_event() function is used to detect command completion. The interrupt handler will set the wait condition variable when the interrupt is triggered. However, the variable used for wait_event() is initialized after the command has been

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

On Wed, Jul 4, 2018 at 8:32 PM, Stephen Rothwell wrote: > I have just removed that commit from the linux-next copy of mmotm (it > was actually commit 026f20c65973 since Andrew did another release > yesterday). Thanks, Stephen!

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

Hi all, On Wed, 4 Jul 2018 10:41:17 -0600 Logan Gunthorpe wrote: > > On 7/4/2018 10:23 AM, Fabio Estevam wrote: > > From: Fabio Estevam > > > > This reverts commit 46e4bf08f6388ba748597275012d715d5e1861e6. > > > > Commit 46e4bf08f6388 ("crypto: caam: cleanup CONFIG_64BIT ifdefs > > when using

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

On 7/4/2018 10:23 AM, Fabio Estevam wrote: > From: Fabio Estevam > > This reverts commit 46e4bf08f6388ba748597275012d715d5e1861e6. > > Commit 46e4bf08f6388 ("crypto: caam: cleanup CONFIG_64BIT ifdefs > when using io{read|write}64") causes kernel crash on imx6 systems: > > [2.041187]

Re: linux-next crash in CAAM driver

On Tue, Jul 3, 2018 at 11:18 AM, Fabio Estevam wrote: > Hi Horia, > > I am not able to boot linux-next 20180703 on imx6 due to a problem > with the CAAM driver. which is caused by the following commit: commit 46e4bf08f6388ba748597275012d715d5e1861e6 Author: Logan Gunthorpe Date: Thu Jun 28

Re: [PATCH 9/9 v2] crypto: atmel-ecc: Break out lock check helper

On 06/28/2018 04:07 PM, Linus Walleij wrote: > This breaks out a lock status checker to be used with further > refactorings. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Rebased > --- > drivers/crypto/atmel-ecc.c | 38 ++ > 1 file

Re: [PATCH 7/9 v2] crypto: atmel-ecc: Print out serial number

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > This reads out the serial number of the crypto chip and prints it, > also toss this into the entropy pool as it is device-unique data. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - kfree(cmd) was missed. Fix it with a

Re: [PATCH 6/9 v2] crypto: atmel-ecc: Marshal the command while sending

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > Instead of casting the struct for the command into (u8 *) > which is problematic in many ways, and instead of > calculating the CRC sum in a separate function, marshal, > checksum and send the command in one single function. > > Instead

Re: [PATCH 3/9 v2] crypto: atmel-ecc: More helpful error messages

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > Report errors once when they happen on the I2C bus so we > get good information in cases such as when the wrong I2C > address is used. > > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - Strip some comments that are now

Re: [PATCH 2/9 v2] crypto: atmel-ecc: Just warn on missing clock frequency

Hi, Linus, On 06/28/2018 04:07 PM, Linus Walleij wrote: > The Atmel ECC driver contains a check for the I2C bus clock > frequency, so as to check that the I2C adapter in use > satisfies the device specs. > > If the device is connected to a device tree node that does not > contain a clock

Re: [PATCH] crypto: arm/speck - fix building in Thumb2 mode

On Mon, Jun 18, 2018 at 03:33:23PM -0700, Eric Biggers wrote: > Building the kernel with CONFIG_THUMB2_KERNEL=y and > CONFIG_CRYPTO_SPECK_NEON set fails with the following errors: > > arch/arm/crypto/speck-neon-core.S: Assembler messages: > > arch/arm/crypto/speck-neon-core.S:419: Error:

Re: [PATCH 0/4] crypto: vmac - various fixes

On Mon, Jun 18, 2018 at 10:22:36AM -0700, Eric Biggers wrote: > From: Eric Biggers > > Hi, this series fixes various bugs in the VMAC template (crypto/vmac.c). > First, the per-request context was being stored in the transform > context, which made VMAC not thread-safe, and the kernel could be >

Re: [PATCH 5/6] crypto: skcipher - remove useless setting of type flags

On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote: > From: Eric Biggers > > Some skcipher algorithms set .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER. But > this is redundant with the C structure type ('struct skcipher_alg'), and > crypto_register_skcipher() already sets the type flag automatically,

Re: [PATCH 3/6] crypto: ahash - remove useless setting of cra_type

On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote: > From: Eric Biggers > > Some ahash algorithms set .cra_type = _ahash_type. But this is > redundant with the C structure type ('struct ahash_alg'), and > crypto_register_ahash() already sets the .cra_type automatically. > Apparently the

Re: [PATCH 2/6] crypto: ahash - remove useless setting of type flags

On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote: > From: Eric Biggers > > Many ahash algorithms set .cra_flags = CRYPTO_ALG_TYPE_AHASH. But this > is redundant with the C structure type ('struct ahash_alg'), and > crypto_register_ahash() already sets the type flag automatically, > clearing

Re: [PATCH 3/5] crypto: testmgr - Improve compression/decompression test

Hi Eric, sorry for my late response. On Fri, Jun 22, 2018 at 08:12:26PM -0700, Eric Biggers wrote: > Hi Jan, > > On Fri, Jun 22, 2018 at 04:37:20PM +0200, Jan Glauber wrote: > > While commit 336073840a87 ("crypto: testmgr - Allow different compression > > results") > > allowed to test

Re: [PATCH 4/9] crypto: atmel-ecc: Provide config zone defines

On Tue, Jun 12, 2018 at 2:59 PM Tudor Ambarus wrote: > On 06/05/2018 04:49 PM, Linus Walleij wrote: > > The config zone has 0x16 words of 4 bytes each, so provide > > some basic defines so that we can address these individually. > > Are you going to use all these defines? I would add just the

Re: [PATCH 8/9] crypto: atmel-ecc: Detail what is unlocked

On Tue, Jun 12, 2018 at 3:25 PM Tudor Ambarus wrote: > On 06/05/2018 04:49 PM, Linus Walleij wrote: > > Instead of just providing a broad error message about the > > chip being unlocked provide details on what is unlocked, > > one line per thing that can be locked: data and OTP and > >

Re: [PATCH 7/9] crypto: atmel-ecc: Print out serial number

On Tue, Jun 12, 2018 at 3:13 PM Tudor Ambarus wrote: > > +#include > > includes should be ordered alphabetically. OK fixed. > > +static int atmel_ecc_get_serial(struct i2c_client *client) > > +{ > > + struct atmel_ecc_cmd *cmd; > > + u8 serial[9]; > > int i, ret; before serial to

Re: [PATCH 6/9] crypto: atmel-ecc: Marshal the command while sending

On Tue, Jun 12, 2018 at 12:19 PM Tudor Ambarus wrote: > The struct atmel_ecc_cmd (__packed) is composed of u8 members with only > 2 exceptions, u16 param2 and u16 crc that were written in little endian, > as the device expects. The (u8 *) cast will point to the first member, > which is u8 as

Re: [PATCH 3/9] crypto: atmel-ecc: More helpful error messages

On Tue, Jun 12, 2018 at 2:36 PM Tudor Ambarus wrote: > On 06/05/2018 04:49 PM, Linus Walleij wrote: > > /* send the command */ > > I guess that this comment will become superfluous if you're going to add > an error message. OK stripped obvious comments. > > - return

Re: [PATCH 2/9] crypto: atmel-ecc: Silently ignore missing clock frequency

On Mon, Jun 11, 2018 at 11:46 AM Tudor Ambarus wrote: > On 06/05/2018 04:49 PM, Linus Walleij wrote: > > The Atmel ECC driver contains a check for the I2C bus clock > > frequency, so as to check that the I2C adapter in use > > satisfies the device specs. > > > > If the device is connected to a

Re: [PATCH v2 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

Hi Rob, On Tue, Jun 26, 2018 at 11:24 AM, Rob Herring wrote: >> Would it be OK to use: compatible = "fsl,imx51-sahara", "fsl,imx53-sahara"; ? > > Yes, but the order should be reversed as it should be most specific > and newest first. Thanks for the feedback. Just sent a dts patch as you

Re: [RFC PATCH] crypto: DH - add public key verification test

Am Dienstag, 26. Juni 2018, 12:17:42 CEST schrieb Stephan Müller: Hi, > + MPI val = mpi_alloc(0); I just saw that I did not check for val after allocation. That will be fixed in another installment of the patch. Ciao Stephan

Re: [PATCH v2 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

On Mon, Jun 25, 2018 at 2:27 PM Fabio Estevam wrote: > > Hi Rob, > > On Mon, Jun 25, 2018 at 5:21 PM, Rob Herring wrote: > > > Looks like imx51 should be a fallback and you can drop the driver > > change. > > I thought about that too. > > If I do like this in imx51.dtsi: > > compatible =

Re: [PATCH v2 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

Hi Rob, On Mon, Jun 25, 2018 at 5:21 PM, Rob Herring wrote: > Looks like imx51 should be a fallback and you can drop the driver > change. I thought about that too. If I do like this in imx51.dtsi: compatible = "fsl,imx51-sahara", "fsl,imx53-sahara"; Then the driver works just fine. I was

Re: [PATCH v2 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

On Fri, Jun 22, 2018 at 03:45:28PM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > i.MX51 and i.MX53 share the same sahara IP block version, so add > i.MX51 in the list of supported SoCs. > > Signed-off-by: Fabio Estevam > --- > Changes since v1: > - Fix typo in commit log "i.MX51 and

Re: [PATCH 4/5] crypto: testmgr - Add test vectors for LZS compression

On Fri, Jun 22, 2018 at 07:50:02PM -0700, Eric Biggers wrote: > Hi Jan, > > On Fri, Jun 22, 2018 at 04:37:21PM +0200, Jan Glauber wrote: > > The test vectors were generated using the ThunderX ZIP coprocessor. > > > > Signed-off-by: Jan Glauber > > --- > > crypto/testmgr.c | 9 ++ > >

Re: [PATCH 3/5] crypto: testmgr - Improve compression/decompression test

Hi Jan, On Fri, Jun 22, 2018 at 04:37:20PM +0200, Jan Glauber wrote: > While commit 336073840a87 ("crypto: testmgr - Allow different compression > results") > allowed to test non-generic compression algorithms there are some corner > cases that would not be detected in test_comp(). > > For

Re: [PATCH 4/5] crypto: testmgr - Add test vectors for LZS compression

Hi Jan, On Fri, Jun 22, 2018 at 04:37:21PM +0200, Jan Glauber wrote: > The test vectors were generated using the ThunderX ZIP coprocessor. > > Signed-off-by: Jan Glauber > --- > crypto/testmgr.c | 9 ++ > crypto/testmgr.h | 77 > 2 files

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 06/22/2018 01:03 PM, Timur Tabi wrote: Perhaps it's because you implemented the 'wait' functionality in this driver? Before the patch there wasn't any sort of wait check so we would bail out if there wasn't any data even if the caller requested that we wait for randomness to be available.

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 6/22/18 12:51 PM, Stephen Boyd wrote: Perhaps it's because you implemented the 'wait' functionality in this driver? Before the patch there wasn't any sort of wait check so we would bail out if there wasn't any data even if the caller requested that we wait for randomness to be available.

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

Quoting Timur Tabi (2018-06-22 08:41:11) > On 6/22/18 10:38 AM, Stanimir Varbanov wrote: > > Before entering into the read function we already hold a mutex which > > serializes data reading so I cannot imagine how below sequence could > > happen. Can you explain how to reproduce this race? > > >

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 6/22/18 10:38 AM, Stanimir Varbanov wrote: Before entering into the read function we already hold a mutex which serializes data reading so I cannot imagine how below sequence could happen. Can you explain how to reproduce this race? 1. Core 1 reads status register, shows data is available.

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

Hi, On 06/21/2018 06:17 PM, Timur Tabi wrote: > The hwrng.read callback includes a boolean parameter called 'wait' > which indicates whether the function should block and wait for > more data. > > When 'wait' is true, the driver spins on the DATA_AVAIL bit or until > a reasonable timeout. The

Re: [PATCH] crypto: cavium: make structure algs static

On Fri, Jun 01, 2018 at 02:12:27PM +0100, Colin King wrote: > From: Colin Ian King > > The structure algs is local to the source and does not need to be in > global scope, so make it static. > > Cleans up sparse warning: > drivers/crypto/cavium/cpt/cptvf_algs.c:354:19: warning: symbol 'algs' >

Re: [PATCH] crypto: atmel-ecc - fix to allow multi segment scatterlists

On Wed, Jun 13, 2018 at 04:29:58PM +0300, Tudor Ambarus wrote: > Remove the limitation of single element scatterlists. ECDH with > multi-element scatterlists is needed by TPM. > > Similar to 'commit 95ec01ba1ef0 ("crypto: ecdh - fix to allow multi > segment scatterlists")'. > > Signed-off-by:

Re: [PATCH 00/10] crypto: inside-secure - sha512/384 support

On Tue, May 29, 2018 at 02:13:42PM +0200, Antoine Tenart wrote: > Hello Herbert, > > This series adds support for the SHA512 and SHA384 algorithms in the > Inside Secure SafeXcel driver. Variants of those two algorithms are also > added as well (hmac, and AEAD). > > Before doing so a few patches

Re: [PATCH] crypto: atmel-ecc - remove overly verbose dev_info

On Wed, Jun 13, 2018 at 04:29:59PM +0300, Tudor Ambarus wrote: > Remove it because when using a slow console, it can affect > the speed of crypto operations. > > Similar to 'commit 730f23b66095 ("crypto: vmx - Remove overly > verbose printk from AES XTS init")'. > > Signed-off-by: Tudor Ambarus

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 6/22/18 12:36 AM, Stephen Boyd wrote: Quoting Timur Tabi (2018-06-21 08:17:55) @@ -96,11 +110,39 @@ static int msm_rng_read(struct hwrng *hwrng, void *data, size_t max, bool wait) /* read random data from hardware */ do { - val = readl_relaxed(rng->base +

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

Quoting Timur Tabi (2018-06-21 08:17:55) > @@ -96,11 +110,39 @@ static int msm_rng_read(struct hwrng *hwrng, void *data, > size_t max, bool wait) > > /* read random data from hardware */ > do { > - val = readl_relaxed(rng->base + PRNG_STATUS); > - if

Re: [PATCH 2/2] hwrng: msm: add ACPI support

On 21-06-18, 23:46, Timur Tabi wrote: > On 6/21/18 11:44 PM, Vinod wrote: > > So this make me think you should do 2 level support for ACPI, one ACPI > > support and one V2 support where we dont touch CONFIG register. That way > > both regions will work > > The ACPI system is a v2 system. If you

Re: [PATCH 2/2] hwrng: msm: add ACPI support

On 6/21/18 11:44 PM, Vinod wrote: So this make me think you should do 2 level support for ACPI, one ACPI support and one V2 support where we dont touch CONFIG register. That way both regions will work The ACPI system is a v2 system. If you want, I can just remove the read of the CONFIG

Re: [PATCH 2/2] hwrng: msm: add ACPI support

On 21-06-18, 23:26, Timur Tabi wrote: > On 6/21/18 11:23 PM, Vinod wrote: > > On 21-06-18, 10:17, Timur Tabi wrote: > > > Add support for probing on ACPI systems, with ACPI HID QCOM8160. > > > > > > On ACPI systems, clocks are always enabled, the PRNG should > > > already be enabled, and the

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 6/21/18 11:24 PM, Vinod wrote: On 21-06-18, 23:18, Timur Tabi wrote: On 6/21/18 11:17 PM, Vinod wrote: this should be a separate patch What exactly should be a separate patch? This part? - rng->hwrng.name = KBUILD_MODNAME, - rng->hwrng.init = msm_rng_init, -

Re: [PATCH 2/2] hwrng: msm: add ACPI support

On 6/21/18 11:23 PM, Vinod wrote: On 21-06-18, 10:17, Timur Tabi wrote: Add support for probing on ACPI systems, with ACPI HID QCOM8160. On ACPI systems, clocks are always enabled, the PRNG should already be enabled, and the register region is read-only. The driver only verifies that the

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 21-06-18, 23:18, Timur Tabi wrote: > On 6/21/18 11:17 PM, Vinod wrote: > > this should be a separate patch > > What exactly should be a separate patch? This part? > > - rng->hwrng.name = KBUILD_MODNAME, > - rng->hwrng.init = msm_rng_init, > - rng->hwrng.cleanup = msm_rng_cleanup,

Re: [PATCH 2/2] hwrng: msm: add ACPI support

On 21-06-18, 10:17, Timur Tabi wrote: > Add support for probing on ACPI systems, with ACPI HID QCOM8160. > > On ACPI systems, clocks are always enabled, the PRNG should > already be enabled, and the register region is read-only. > The driver only verifies that the hardware is already > enabled

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 6/21/18 11:17 PM, Vinod wrote: this should be a separate patch What exactly should be a separate patch? This part? - rng->hwrng.name = KBUILD_MODNAME, - rng->hwrng.init = msm_rng_init, - rng->hwrng.cleanup = msm_rng_cleanup, - rng->hwrng.read = msm_rng_read, +

Re: [PATCH 1/2] hwrng: msm: add a spinlock and support for blocking reads

On 21-06-18, 10:17, Timur Tabi wrote: > The hwrng.read callback includes a boolean parameter called 'wait' > which indicates whether the function should block and wait for > more data. > > When 'wait' is true, the driver spins on the DATA_AVAIL bit or until > a reasonable timeout. The timeout

Re: [PATCH] crypto: arm/speck - fix building in Thumb2 mode

On 19.06.2018 00:33, Eric Biggers wrote: > Building the kernel with CONFIG_THUMB2_KERNEL=y and > CONFIG_CRYPTO_SPECK_NEON set fails with the following errors: > > arch/arm/crypto/speck-neon-core.S: Assembler messages: > > arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here

Re: [PATCH] crypto: arm/speck - fix building in Thumb2 mode

On 19 June 2018 at 00:33, Eric Biggers wrote: > Building the kernel with CONFIG_THUMB2_KERNEL=y and > CONFIG_CRYPTO_SPECK_NEON set fails with the following errors: > > arch/arm/crypto/speck-neon-core.S: Assembler messages: > > arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed

Re: [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

On 18 June 2018 at 23:56, Eric Biggers wrote: > On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote: >> > + >> > + // One-time XTS preparation >> > + >> > + /* >> > + * Allocate stack space to store 128 bytes worth of tweaks. For >> > + *

Re: [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

On Sun, Jun 17, 2018 at 01:10:41PM +0200, Ard Biesheuvel wrote: > > + > > + // One-time XTS preparation > > + > > + /* > > + * Allocate stack space to store 128 bytes worth of tweaks. For > > + * performance, this space is aligned to a 16-byte boundary so

Re: [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

On 17 June 2018 at 12:41, Stefan Agner wrote: > On 17.06.2018 11:40, Ard Biesheuvel wrote: >> On 17 June 2018 at 11:30, Ard Biesheuvel wrote: >>> On 17 June 2018 at 00:40, Stefan Agner wrote: Hi Eric, On 14.02.2018 19:42, Eric Biggers wrote: > Add an ARM NEON-accelerated

Re: [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

On 17.06.2018 11:40, Ard Biesheuvel wrote: > On 17 June 2018 at 11:30, Ard Biesheuvel wrote: >> On 17 June 2018 at 00:40, Stefan Agner wrote: >>> Hi Eric, >>> >>> On 14.02.2018 19:42, Eric Biggers wrote: Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on 128-byte

Re: [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

On 17 June 2018 at 11:30, Ard Biesheuvel wrote: > On 17 June 2018 at 00:40, Stefan Agner wrote: >> Hi Eric, >> >> On 14.02.2018 19:42, Eric Biggers wrote: >>> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on >>> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16

Re: [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

On 17 June 2018 at 00:40, Stefan Agner wrote: > Hi Eric, > > On 14.02.2018 19:42, Eric Biggers wrote: >> Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on >> 128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for >> Speck64. Each 128-byte chunk goes through

Re: [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS

eY3, r12, TMP0 > + vswpX0_L, Y0_H > + vswpX1_L, Y1_H > + vswpX2_L, Y2_H > + vswpX3_L, Y3_H > +.else > + _xts64_precrypt_two X0, r12, TMP0 > + _xts64_precrypt_two Y0, r12, TMP0 > +

Re: [PATCH] crypto: don't optimize keccakf()

On Fri, Jun 08, 2018 at 11:53:41AM +0200, Dmitry Vyukov wrote: > keccakf() is the only function in kernel that uses __optimize() macro. > __optimize() breaks frame pointer unwinder as optimized code uses RBP, > and amusingly this always lead to degraded performance as gcc does not > inline across

Re: [PATCH v2] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin,_end

Jia He wrote: > In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]: > [7.019116] BUG: sleeping function called from invalid context at > ./include/crypto/algapi.h:416 > [7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name: > cryptomgr_test > [7.035106] 1

Re: [PATCH] crypto: morus640 - Fix out-of-bounds access

On Wed, Jun 13, 2018 at 04:44:17PM +0200, Ondrej Mosnacek wrote: > We must load the block from the temporary variable here, not directly > from the input. > > Also add forgotten zeroing-out of the uninitialized part of the > temporary block (as is done correctly in morus1280.c). > > Fixes:

Re: [PATCH V3 1/2] evm: Don't deadlock if a crypto algorithm is unavailable

On Wed, 2018-06-13 at 14:33 +0800, Herbert Xu wrote: > On Fri, Jun 08, 2018 at 02:57:42PM -0700, Matthew Garrett wrote: > > When EVM attempts to appraise a file signed with a crypto algorithm the > > kernel doesn't have support for, it will cause the kernel to trigger a > > module load. If the EVM

Re: [PATCH V3 1/2] evm: Don't deadlock if a crypto algorithm is unavailable

On Fri, Jun 08, 2018 at 02:57:42PM -0700, Matthew Garrett wrote: > When EVM attempts to appraise a file signed with a crypto algorithm the > kernel doesn't have support for, it will cause the kernel to trigger a > module load. If the EVM policy includes appraisal of kernel modules this > will in

Re: [PATCH V2 1/2] evm: Don't deadlock if a crypto algorithm is unavailable

On Wed, Jun 06, 2018 at 02:57:11PM -0700, Matthew Garrett wrote: > When EVM attempts to appraise a file signed with a crypto algorithm the > kernel doesn't have support for, it will cause the kernel to trigger a > module load. If the EVM policy includes appraisal of kernel modules this > will in

Re: [PATCH V3 1/2] evm: Don't deadlock if a crypto algorithm is unavailable

On Fri, Jun 8, 2018 at 2:57 PM Matthew Garrett wrote: > > When EVM attempts to appraise a file signed with a crypto algorithm the > kernel doesn't have support for, it will cause the kernel to trigger a > module load. If the EVM policy includes appraisal of kernel modules this > will in turn call

Re: [PATCH 8/9] crypto: atmel-ecc: Detail what is unlocked

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: Instead of just providing a broad error message about the chip being unlocked provide details on what is unlocked, one line per thing that can be locked: data and OTP and configuration are locked independently. Loose the Failure to lock

Re: [PATCH 7/9] crypto: atmel-ecc: Print out serial number

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: This reads out the serial number of the crypto chip and prints it, also toss this into the entropy pool as it is device-unique data. Signed-off-by: Linus Walleij --- drivers/crypto/atmel-ecc.c | 56

Re: [PATCH 4/9] crypto: atmel-ecc: Provide config zone defines

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: The config zone has 0x16 words of 4 bytes each, so provide some basic defines so that we can address these individually. Are you going to use all these defines? I would add just the defines that are needed, when they are needed, but I

Re: [PATCH 3/9] crypto: atmel-ecc: More helpful error messages

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: Report errors once when they happen on the I2C bus so we get good information in cases such as when the wrong I2C address is used. Signed-off-by: Linus Walleij --- drivers/crypto/atmel-ecc.c | 27 +-- 1 file

Re: [PATCH 1/9] crypto: atmel-ecc: Make available for other platforms

On 06/05/2018 04:49 PM, Linus Walleij wrote: This is a pure I2C driver, and this device appears on the 96boards Secure96 mezzanine card, so we want to enable the driver on other devices. Cut the Kconfig limitations to Atmel SoC only. Signed-off-by: Linus Walleij Reviewed-by: Tudor Ambarus

Re: [PATCH 6/9] crypto: atmel-ecc: Marshal the command while sending

Hi, Linus, On 06/05/2018 04:49 PM, Linus Walleij wrote: Instead of casting the struct for the command into (u8 *) which is problematic in many ways, and instead of calculating the CRC sum in a separate function, marshal, checksum and send the command in one single function. Instead of

Re: [PATCH v11 06/13] crypto: aesni: add minimal build option for SGX LE

On Fri, 2018-06-08 at 10:27 -0700, Dave Hansen wrote: > On 06/08/2018 10:09 AM, Jarkko Sakkinen wrote: > > > > --- a/arch/x86/crypto/aesni-intel_asm.S > > +++ b/arch/x86/crypto/aesni-intel_asm.S > > @@ -45,6 +45,8 @@ > >  #define MOVADQ movaps > >  #define MOVUDQ movups > >   > > +#ifndef

Re: [PATCH 2/9] crypto: atmel-ecc: Silently ignore missing clock frequency

Hi, Linus, Wolfram, On 06/05/2018 04:49 PM, Linus Walleij wrote: The Atmel ECC driver contains a check for the I2C bus clock frequency, so as to check that the I2C adapter in use satisfies the device specs. If the device is connected to a device tree node that does not contain a clock

Re: [PATCH] crypto: don't optimize keccakf()

On 8 June 2018 at 11:53, Dmitry Vyukov wrote: > keccakf() is the only function in kernel that uses __optimize() macro. > __optimize() breaks frame pointer unwinder as optimized code uses RBP, > and amusingly this always lead to degraded performance as gcc does not > inline across different

Re: Q for a new API for the random device driver

On Wed, Jun 06, 2018 at 04:58:29PM +0200, Harald Freudenberger wrote: > Had a short glimpse to the mentioned add_hwgenerator_randomness() > and this looks in fact like the API I am looking for :-) > Thanks Stephan, I'll write some code and check this out. The more convenient interface would be

Re: Q for a new API for the random device driver

On 06.06.2018 16:26, PrasannaKumar Muralidharan wrote: > Hi Herald, > > On 6 June 2018 at 18:18, Harald Freudenberger wrote: >> Hello Theodore, hi Linux Community >> >> my patch for the s390 arch_get_random_seed* implementation is about to >> be integrated with the current merge window for kernel

Re: Q for a new API for the random device driver

On 06.06.2018 15:11, Stephan Mueller wrote: > Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger: > > Hi Harald, >> I am still searching for a way to provide our good hardware entropy >> source to the random pool in the random device driver. So I'd like to >> have a new arch

Re: Q for a new API for the random device driver

Hi Herald, On 6 June 2018 at 18:18, Harald Freudenberger wrote: > Hello Theodore, hi Linux Community > > my patch for the s390 arch_get_random_seed* implementation is about to > be integrated with the current merge window for kernel 4.18. > > So I'd like to start a discussion about a new API for

Re: Q for a new API for the random device driver

Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger: Hi Harald, > > I am still searching for a way to provide our good hardware entropy > source to the random pool in the random device driver. So I'd like to > have a new arch interface which is called when the random pool finds

Re: [PATCH 1/2] evm: Don't deadlock if a crypto algorithm is unavailable

On Sat, Jun 2, 2018 at 8:54 AM Herbert Xu wrote: > > On Fri, Jun 01, 2018 at 04:02:43PM -0700, Matthew Garrett wrote: > > Trying to instantiate a non-existent crypto algorithm will cause the > > kernel to trigger a module load. If EVM appraisal is enabled, this will > > in turn trigger appraisal

Re: [PATCH 1/2] evm: Don't deadlock if a crypto algorithm is unavailable

On Fri, Jun 01, 2018 at 04:02:43PM -0700, Matthew Garrett wrote: > Trying to instantiate a non-existent crypto algorithm will cause the > kernel to trigger a module load. If EVM appraisal is enabled, this will > in turn trigger appraisal of the module, which will fail because the > crypto

Re: [PATCH 0/2] crypto: remove x86 salsa20 implementations

On Sat, May 26, 2018 at 12:08:57AM -0700, Eric Biggers wrote: > Hello, > > The x86 asm implementations of Salsa20 have been missed so far in the > fixes to stop abusing %ebp/%rbp in asm code to get correct stack traces. > This has been causing the unwinder warnings reported by syzkaller to >

Re: [PATCH 0/3] crypto:chelsio: Fixes and cleanup

On Thu, May 24, 2018 at 05:26:36PM +0530, Harsh Jain wrote: > It includes Fixes and cleanup . > > Harsh Jain (3): > crypto:chelsio:Return -ENOSPC for transient busy indication. > crypt:chelsio:Send IV as Immediate for cipher algo > crypto:chelsio: Remove separate buffer used for DMA map B0

Re: [PATCH] crypto: clarify licensing of OpenSSL asm code

On Tue, May 22, 2018 at 12:35:11PM -0700, Adam Langley wrote: > Several source files have been taken from OpenSSL. In some of them a > comment that "permission to use under GPL terms is granted" was > included below a contradictory license statement. In several cases, > there was no indication

Re: [PATCH 1/3] crypto: caam - fix MC firmware detection

On Wed, May 23, 2018 at 02:32:40PM +0300, Horia Geantă wrote: > Management Complex (MC) f/w detection is based on CTPR_MS[DPAA2] bit. > > This is incorrect since: > -the bit is set for all CAAM blocks integrated in SoCs with a certain > Layerscape Chassis > -some SoCs with LS Chassis don't have

Re: [PATCH v2] crypto: Mark MORUS SIMD glue as x86-specific

On Mon, May 21, 2018 at 09:41:51PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for > MORUS") accidetally consiedered the glue code to be usable by different > architectures, but it seems to be only usable on x86. > >

Re: [PATCH 0/5] crypto: eliminate redundant decryption test vectors

On Sun, May 20, 2018 at 10:50:24PM -0700, Eric Biggers wrote: > Hello, > > When adding the Speck cipher support I was annoyed by having to add both > encryption and decryption test vectors, since they are redundant: the > decryption ones are just the encryption ones with the input and result >

Re: PBKDF2 support in the linux kernel

On Sun, May 27, 2018 at 01:22:05PM +0200, Rafael J. Wysocki wrote: > Again, the PBKDF2 user would be hibernation. It could either take a key from > user space, which would require a key-generating user-space component to be > present in the initramfs (I guess no issue for a regular distro, but I

Re: PBKDF2 support in the linux kernel

On Saturday, May 26, 2018 7:12:36 AM CEST Herbert Xu wrote: > On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote: > > Hi all, > > The request is that, we'd like to generate a symmetric key derived from > > user provided passphase(not rely on any third-party library). May I know if > > there

Re: PBKDF2 support in the linux kernel

On Sat, May 26, 2018 at 03:36:37PM +0200, Stephan Mueller wrote: > - security related code should be vetted (which arguably is the case when the > discussed PBKDF is part of the kernel) > > > > If he/she were to add their own userland code then he would surely be > > criticized for rolling his

Re: KASAN: use-after-free Read in crypto_destroy_tfm

On Sat, May 26, 2018 at 7:40 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:0644f186fc9d Merge tag 'for_linus' of git://git.kernel.org.. > git tree: upstream > console output:

Re: [PATCH] crypto: x86/aegis256 - Fix wrong key buffer size

On Sun, May 20, 2018 at 10:57:23AM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > AEGIS-256 key is two blocks, not one. > > Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") > Reported-by: Eric Biggers >

Re: [PATCH 0/6] crypto: crc32 cleanups and unkeyed tests

On Sat, May 19, 2018 at 10:07:36PM -0700, Eric Biggers wrote: > This series fixes up alignment for crc32-generic and crc32c-generic, > removes test vectors for bfin_crc that are no longer needed, and adds > unkeyed test vectors for crc32 and an extra unkeyed test vector for > crc32c. Adding the

Re: [PATCH] crypto: chtls - fix a missing-check bug

On Fri, May 18, 2018 at 02:55:35PM -0500, Wenwen Wang wrote: > In do_chtls_setsockopt(), the tls crypto info is first copied from the > poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the > 'version' of the crypto info is checked. If the version is not as expected, > i.e.,

Re: [PATCH] crypto: inside-secure - do not use memset on MMIO

On Thu, May 17, 2018 at 03:22:14PM +0200, Antoine Tenart wrote: > This patch fixes the Inside Secure driver which uses a memtset() call to > set an MMIO area from the cryptographic engine to 0. This is wrong as > memset() isn't guaranteed to work on MMIO for many reasons. This led to > kernel

Re: [PATCH v2 00/10] crypto: inside-secure - AEAD support

On Mon, May 14, 2018 at 03:10:54PM +0200, Antoine Tenart wrote: > This series brings AEAD algorithms to the Inside Secure SafeXcel driver. > The first 7 commits rework the driver to allow the future AEAD addition, > and then 3 commits add AEAD functions and 3 algorithms. > > This is based on top

Re: [PATCH] crypto: chtls: generic handling of data and hdr

On Mon, May 14, 2018 at 04:41:38PM +0530, Atul Gupta wrote: > removed redundant check and made TLS PDU and header recv > handling common as received from HW. > Ensure that only tls header is read in cpl_rx_tls_cmp > read-ahead and skb is freed when entire data is processed. > > Signed-off-by:

Re: PBKDF2 support in the linux kernel

Am Samstag, 26. Mai 2018, 14:17:11 CEST schrieb Jeffrey Walton: Hi Jeffrey, > On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > > > Hi Rafael, > > > >> So the problem is that Yu would

<    1   2   3   4   5   6   7   8   9   10   >