Re: [PATCH/RFC] crypto: Add platform dependencies for CRYPTO_DEV_CCREE

On Tue, Apr 17, 2018 at 8:14 PM, Geert Uytterhoeven wrote: > The ARM TrustZone CryptoCell is found on ARM SoCs only. Hence make it > depend on ARM or ARM64, unless compile-testing. > > Drop the dependency on HAS_DMA, as DMA is always available on ARM and > ARM64 platforms,

RE: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

>-Original Message- >From: Herbert Xu [mailto:herb...@gondor.apana.org.au] >Sent: Friday, March 16, 2018 7:54 AM >To: Dey, Megha <megha@intel.com> >Cc: linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org; >da...@davemloft.net >Subject: Re: [PATCH V

Re: [PATCH v2] X.509: unpack RSA signatureValue field from BIT STRING

On 17.04.2018 17:07, Kamil Konieczny wrote: > > > On 17.04.2018 15:39, Maciej S. Szmigiero wrote: >> The signatureValue field of a X.509 certificate is encoded as a BIT STRING. >> For RSA signatures this BIT STRING is of so-called primitive subtype, which >> contains a u8 prefix indicating a

Re: [PATCH v2] X.509: unpack RSA signatureValue field from BIT STRING

On 17.04.2018 15:39, Maciej S. Szmigiero wrote: > The signatureValue field of a X.509 certificate is encoded as a BIT STRING. > For RSA signatures this BIT STRING is of so-called primitive subtype, which > contains a u8 prefix indicating a count of unused bits in the encoding. > > We have to

Re: [PATCH v2] crypto: caam: - Use kmemdup() function

On 4/16/2018 7:07 PM, Fabio Estevam wrote: > From: Fabio Estevam > > Use kmemdup() rather than duplicating its implementation. > > By usign kmemdup() we can also get rid of the 'val' variable. > > Detected with Coccinelle script. > > Signed-off-by: Fabio Estevam

Re: [PATCH] crypto: caam - strip input zeros from RSA input buffer

On Mon, Apr 16, 2018 at 10:34 AM, Horia Geantă wrote: > Sometimes the provided RSA input buffer provided is not stripped > of leading zeros. This could cause its size to be bigger than that > of the modulus, making the HW complain: > > caam_jr 2142000.jr1: 4789: DECO:

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

On Mon, Apr 16, 2018 at 07:34:29PM +, Yann Collet wrote: > Hi Singh > > I don't have any strong opinion on this topic. > > You made your case clear: > your variant trades a little bit of speed for a little bit more compression > ratio. > In the context of zram, it makes sense, and I would

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

Hi Singh I don't have any strong opinion on this topic. You made your case clear: your variant trades a little bit of speed for a little bit more compression ratio. In the context of zram, it makes sense, and I would expect it to work, as advertised in your benchmark results. (disclaimer: I

Re: [PATCH v2] crypto/ecc: Actually remove stack VLA usage

On Fri, Mar 30, 2018 at 9:55 AM, Kees Cook wrote: > On the quest to remove all VLAs from the kernel[1], this avoids VLAs > by just using the maximum allocation size (4 bytes) for stack arrays. > All the VLAs in ecc were either 3 or 4 bytes (or a multiple), so just > make it

Re: [PATCH RESEND] crypto: caam - strip input zeros from RSA input buffer

On 04/16/2018 04:07 PM, Horia Geantă wrote: Sometimes the provided RSA input buffer provided is not stripped of leading zeros. This could cause its size to be bigger than that of the modulus, making the HW complain: caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - A

Re: [PATCH] crypto: caam: - Use kmemdup() function

On 4/16/2018 5:08 PM, Fabio Estevam wrote: > From: Fabio Estevam > > Use kmemdup() rather than duplicating its implementation. > > Detected with Coccinelle script. > > Signed-off-by: Fabio Estevam > --- > drivers/crypto/caam/caampkc.c | 4 +--- >

Re: [PATCH] crypto: caam: - Use kmemdup() function

On Mon, Apr 16, 2018 at 11:05:14AM -0300, Fabio Estevam wrote: > From: Fabio Estevam > > Use kmemdup() rather than duplicating its implementation. > > Detected with Coccinelle script. > > Signed-off-by: Fabio Estevam > --- >

Re: [PATCH RESEND] crypto: caam - strip input zeros from RSA input buffer

On Mon, Apr 16, 2018 at 10:07 AM, Horia Geantă wrote: > Sometimes the provided RSA input buffer provided is not stripped > of leading zeros. This could cause its size to be bigger than that > of the modulus, making the HW complain: > > caam_jr 2142000.jr1: 4789: DECO:

Re: [PATCH v3] crypto: caam: Drop leading zero from input buffer

On 4/15/2018 6:51 PM, Martin Townsend wrote: > On Sun, Apr 15, 2018 at 3:12 PM, Fabio Estevam wrote: >> From: Fabio Estevam >> >> imx6ul and imx7 report the following error: >> >> caam_jr 2142000.jr1: 4789: DECO: desc idx 7: >> Protocol Size Error -

Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.

 Hello Nick/ Yann, Any inputs regarding LZ4 dyn results & lz4 dyn approach. >Hello Nick/Sergey, > >Any suggestion or comments, so that we can change code and resend the patch? > >> Hi Nick / Sergey, >> >> >> We have compared LZ4 Dyn with Original LZ4 using some samples of realtime >>

Re: [PATCH v3] crypto: caam: Drop leading zero from input buffer

On Sun, Apr 15, 2018 at 3:12 PM, Fabio Estevam wrote: > From: Fabio Estevam > > imx6ul and imx7 report the following error: > > caam_jr 2142000.jr1: 4789: DECO: desc idx 7: > Protocol Size Error - A protocol has seen an error in size. When > running

Re: [PATCH v2] crypto: caam: Drop leading zero from input buffer

On Sun, Apr 15, 2018 at 10:52 AM, Martin Townsend wrote: > Sorry to be a pain but looking at the other use cases for > caam_rsa_drop_leading_zeros they check len afterwards which makes more > sense to me as temp being NULL after this operation is very unlikely > :) and I

Re: [PATCH v2] crypto: caam: Drop leading zero from input buffer

On Sun, Apr 15, 2018 at 12:03 PM, Fabio Estevam wrote: > From: Fabio Estevam > > imx6ul and imx7 report the following error: > > caam_jr 2142000.jr1: 4789: DECO: desc idx 7: > Protocol Size Error - A protocol has seen an error in size. When >

Re: [PATCH] crypto: caam: Drop leading zero from input buffer

Hi Martin, On Sun, Apr 15, 2018 at 5:01 AM, Martin Townsend wrote: > Fixing these things I have tested the patch on my board and have not > seen any issues yet and it has booted to the prompt and I've checked > /sys/kernel/security/ima/ascii_runtime_measurements and can

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Horia, On Fri, Apr 13, 2018 at 3:18 AM, Horia Geantă wrote: > Stripping should happen before set_rsa_pub_pdb() is called since the Protocol > Data Block contains the input length that is used by the accelerator: > pdb->f_len = req->src_len; > > It should

Re: [PATCH 2/2] ARM: bcm283x: Add missing interrupt for RNG block

On Sat, 18 Nov 2017 14:04:13 +0100, Stefan Wahren wrote: > This patch adds the missing interrupt property to the RNG block > of BCM283x. > > Link: https://github.com/raspberrypi/linux/issues/2195 > CC: Florian Fainelli > Signed-off-by: Stefan

Re: [PATCH 1/2] dt-binding: rng: Add interrupt property for BCM2835

On 11/18/2017 05:04 AM, Stefan Wahren wrote: > As Sylvain Garrigues pointed out the BCM2835 RNG block has an > interrupt. Also in preparation for Florian's upcoming patch series > add this property to the binding. While we are at it fix the > indenting of the example. > > Link:

Re: [PATCH 1/5] random: fix crng_ready() test

Am Freitag, 13. April 2018, 14:53:13 CEST schrieb Theodore Y. Ts'o: Hi Theodore, > > This was always the original design intent, but I screwed up and no > one noticed until Jann reached out to be and said, "Hey this > doesn't seem to make much sense". I disagree, but I guess you would have

Re: [PATCH 1/5] random: fix crng_ready() test

On Fri, Apr 13, 2018 at 07:38:30AM +0200, Stephan Mueller wrote: > > The crng_init variable has three states: > > > > 0: The CRNG is not initialized at all > > 1: The CRNG has a small amount of entropy, hopefully good enough for > >early-boot, non-cryptographical use cases > > 2: The CRNG is

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On 4/13/2018 3:12 AM, Fabio Estevam wrote: > Hi Horia, > > On Thu, Apr 12, 2018 at 4:12 AM, Horia Geantă wrote: > >> Yes, driver needs to strip off leading zeros from input data before feeding >> it >> to the accelerator. >> I am working at a fix. > > I was able to to

Re: [PATCH 1/5] random: fix crng_ready() test

Am Freitag, 13. April 2018, 03:30:42 CEST schrieb Theodore Ts'o: Hi Theodore, > The crng_init variable has three states: > > 0: The CRNG is not initialized at all > 1: The CRNG has a small amount of entropy, hopefully good enough for >early-boot, non-cryptographical use cases > 2: The CRNG

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Horia, On Thu, Apr 12, 2018 at 4:12 AM, Horia Geantă wrote: > Yes, driver needs to strip off leading zeros from input data before feeding it > to the accelerator. > I am working at a fix. I was able to to strip off the leading zeros from input data as you suggested.

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

Hi Fabio, 2018-04-11 9:45 GMT-03:00 Fabio Estevam : > From: Fabio Estevam > > The 'era' information can be retrieved from CAAM registers, so > introduce a caam_get_era_from_hw() function that gets it via register > reads in case the 'fsl,sec-era'

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On 4/11/2018 8:26 PM, Fabio Estevam wrote: > Hi Horia, > > On Wed, Apr 11, 2018 at 7:15 AM, Horia Geantă wrote: > >> You'd want to make sure rsa is offloaded to caam in this case - check in >> /proc/crypto. >> IIRC there are some i.mx parts that don't have support for

Re: [PATCH] crypto: drbg - set freed buffers to NULL

On Wed, Apr 11, 2018 at 04:31:01PM +0200, Stephan Müller wrote: > Sorry, this time with the proper subject line. > > ---8<--- > > During freeing of the internal buffers used by the DRBG, set the pointer > to NULL. It is possible that the context with the freed buffers is > reused. In case of an

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Horia, On Wed, Apr 11, 2018 at 7:15 AM, Horia Geantă wrote: > You'd want to make sure rsa is offloaded to caam in this case - check in > /proc/crypto. > IIRC there are some i.mx parts that don't have support for Public Key > acceleration (PKHA). PKHA is present on

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

On Wed, Apr 11, 2018 at 4:26 PM, Stephan Müller wrote: > Hi Dimitry, > > This fix prevents the kernel from crashing when injecting the fault. Good! > Stack traces are yet shown but I guess that is expected every time > a fault is injected. Yes, nothing to fix here. > As

RE: [PATCH v2 0/2] crypto: removing various VLAs

From: Salvatore Mesoraca > Sent: 09 April 2018 17:38 ... > > You can also do much better than allocating MAX_BLOCKSIZE + MAX_ALIGNMASK > > bytes by requesting 'long' aligned on-stack memory. > > The easiest way is to define a union like: > > > > union crypto_tmp { > > u8

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Hi Dimitry, This fix prevents the kernel from crashing when injecting the fault. Stack traces are yet shown but I guess that is expected every time a fault is injected. As to why KASAN did not notice this one, I am not sure. Maybe it is because I use two buffer pointers to point to (almost) the

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

On 4/11/2018 3:45 PM, Fabio Estevam wrote: > From: Fabio Estevam > > The 'era' information can be retrieved from CAAM registers, so > introduce a caam_get_era_from_hw() function that gets it via register > reads in case the 'fsl,sec-era' property is not passed in the

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Mittwoch, 11. April 2018, 14:29:45 CEST schrieb Dmitry Vyukov: Hi Dmitry, > > What do you mean by description of the fault? > It's kernel standard FAULT_INJECTION facility, it injects faults > mainly into kmalloc/slab_alloc (also in a bunch of other things, but > in this case this seems to be

Re: [PATCH v3 2/2] crypto: caam - allow retrieving 'era' from register

On 4/11/2018 2:59 PM, Fabio Estevam wrote: > From: Fabio Estevam > > The 'era' information can be retrieved from CAAM registers, so > introduce a caam_get_era_from_hw() function that gets it via register > reads in case the 'fsl,sec-era' property is not passed in the

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

On Tue, Apr 10, 2018 at 5:35 PM, Stephan Mueller wrote: > Am Dienstag, 10. April 2018, 17:23:46 CEST schrieb Dmitry Vyukov: > > Hi Dmitry, > >> Stephan, >> >> Do you have any hypothesis as to why this is not detected by KASAN and >> causes silent corruptions? >> We generally

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On Wed, Apr 11, 2018 at 11:58 AM, Horia Geantă wrote: > On 4/11/2018 1:36 AM, James Bottomley wrote: >> On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: >>> Using openssl to get the signature in my x509 cert >>> >>>Signature Algorithm: sha256WithRSAEncryption

Re: [PATCH v2 2/2] crypto: caam - allow retrieving 'era' from register

Hi Horia, On Wed, Apr 11, 2018 at 4:47 AM, Horia Geantă wrote: > Have you actually hit a case where the property was missing from DT? Yes, on imx7s.dtsi it is missing. I also started adding CAAM support to mx6ul and I did not pass the ""fsl,sec-era" Thanks for your

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi James, On Tue, Apr 10, 2018 at 11:36 PM, James Bottomley wrote: > On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: >> Using openssl to get the signature in my x509 cert >> >>Signature Algorithm: sha256WithRSAEncryption >>

Re: [RFC PATCH 0/5] KEYS: add kpp keyctl operations

Am Mittwoch, 11. April 2018, 13:08:11 CEST schrieb Tudor Ambarus: Hi Tudor, > Hi, > > There was a long discussion about which interface to chose to export > akcipher and kpp to user-space. This series came as an alternative to > what Stephan proposed for af_alg[1]. I would like some feedback

Re: [RFC PATCH 0/5] KEYS: add kpp keyctl operations

Hi, There was a long discussion about which interface to chose to export akcipher and kpp to user-space. This series came as an alternative to what Stephan proposed for af_alg[1]. I would like some feedback before diving into tpm. Best, ta [1]

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On 4/11/2018 1:36 AM, James Bottomley wrote: > On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: >> Using openssl to get the signature in my x509 cert >> >>    Signature Algorithm: sha256WithRSAEncryption >> 68:82:cc:5d:f9:ee:fb:1a:77:72:a6:a9:c6:4c:cc:d7:f6:2a: >>

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On 4/11/2018 5:21 AM, Fabio Estevam wrote: > Hi Martin, > > On Tue, Apr 10, 2018 at 7:01 PM, Martin Townsend > wrote: > >> A hexdump of the signature reveals a 0x00 at the start > > Yes, same is happening here on my mx6ul evk running linux-next: > [snip] > > However,

Re: [PATCH v2 2/2] crypto: caam - allow retrieving 'era' from register

On 4/11/2018 4:54 AM, Fabio Estevam wrote: > From: Fabio Estevam > > The 'era' information can be retrieved from CAAM registers, so > introduce a caam_get_era_from_hw() function that gets it via register > reads in case the 'fsl,sec-era' property is not passed in the

Re: [PATCH v2 1/2] crypto: caam - staticize caam_get_era()

On 4/11/2018 4:54 AM, Fabio Estevam wrote: > From: Fabio Estevam > > caam_get_era() is only used locally, so do not export this function > and make it static instead. > > Signed-off-by: Fabio Estevam Reviewed-by: Horia Geantă

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Martin, On Tue, Apr 10, 2018 at 7:01 PM, Martin Townsend wrote: > A hexdump of the signature reveals a 0x00 at the start Yes, same is happening here on my mx6ul evk running linux-next: [2.990651] cfg80211: Loading compiled-in X.509 certificates for regulatory

Re: [PATCH v2 1/2] crypto: caam - staticize caam_get_era()

On Tue, Apr 10, 2018 at 10:54 PM, Fabio Estevam wrote: > From: Fabio Estevam > > caam_get_era() is only used locally, so do not export this function > and make it static instead. > > Signed-off-by: Fabio Estevam > --- > Changes

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On Tue, 2018-04-10 at 23:01 +0100, Martin Townsend wrote: > Using openssl to get the signature in my x509 cert > >    Signature Algorithm: sha256WithRSAEncryption > 68:82:cc:5d:f9:ee:fb:1a:77:72:a6:a9:c6:4c:cc:d7:f6:2a: > 17:a5:db:bf:5a:2b:8d:39:60:dc:a0:93:39:45:0f:bc:a7:e8: >  

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

t;> [3.320825] irq event stamp: 186525 >> [3.324504] hardirqs last enabled at (186543): [] >> console_unlock+0x4d4/0x5c8 >> [3.332584] hardirqs last disabled at (186550): [] >> console_unlock+0xc8/0x5c8 >> [ 3.340664] softirqs last enabled at (186566

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

.0: Direct firmware load for > regulatory.db failed with error -2 > [ 3.379780] cfg80211: failed to load regulatory.db > [3.385260] VSD_3V3: disabling > [3.388632] ALSA device list: > [3.391662] #0: mx6ul-wm8960 > [3.536866] EXT4-fs (mmcblk1p2): recovery complete

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

VFS: Mounted root (ext4 filesystem) on device 179:2. [3.587857] devtmpfs: mounted [3.600044] Freeing unused kernel memory: 1024K [3.775667] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) Starting logging: OK Initializing random number generator... done. Starting network: OK Welcome to Bui

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Fabio, On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam wrote: > Hi Martin, > > On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend > wrote: >> Hi, >> >> I'm trying to get to the bottom of an issue I'm seeing when enabling >> the CAAM in the kernel

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Martin, On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend wrote: > Hi, > > I'm trying to get to the bottom of an issue I'm seeing when enabling > the CAAM in the kernel with IMA/EVM enabled. I'm using the official > NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. Does it

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Dienstag, 10. April 2018, 17:23:46 CEST schrieb Dmitry Vyukov: Hi Dmitry, > Stephan, > > Do you have any hypothesis as to why this is not detected by KASAN and > causes silent corruptions? > We generally try to understand such cases and improve KASAN so that it > catches such cases more

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

On Mon, Apr 9, 2018 at 9:57 AM, Dmitry Vyukov wrote: > On Mon, Apr 9, 2018 at 7:40 AM, Stephan Mueller wrote: >> Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o: >> >> Hi Theodore, >>> >>> So the syzbot will run while the patch goes

Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation

On Mon, Apr 09, 2018 at 10:58:08AM +0200, Steffen Klassert wrote: > On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote: > > On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote: > > > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > > > > From: Eric Biggers

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Mike, On Mon, Apr 9, 2018 at 5:53 PM, Mike Rapoport wrote: > (added CAAM maintainers) > > On Mon, Apr 09, 2018 at 03:10:11PM +0100, Martin Townsend wrote: >> Hi Mimi, >> >> On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: >> > On Mon,

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

(added CAAM maintainers) On Mon, Apr 09, 2018 at 03:10:11PM +0100, Martin Townsend wrote: > Hi Mimi, > > On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: > > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: > >> Hi, > >> > >> I'm trying to get to the bottom

Re: [PATCH v2 0/2] crypto: removing various VLAs

2018-04-09 16:35 GMT+02:00 David Laight : > From: Salvatore Mesoraca >> Sent: 09 April 2018 14:55 >> >> v2: >> As suggested by Herbert Xu, the blocksize and alignmask checks >> have been moved to crypto_check_alg. >> So, now, all the other separate checks

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On Mon, 2018-04-09 at 15:10 +0100, Martin Townsend wrote: > Hi Mimi, > > On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: > > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: > >> Hi, > >> > >> I'm trying to get to the bottom of an issue I'm seeing when

RE: [PATCH v2 0/2] crypto: removing various VLAs

From: Salvatore Mesoraca > Sent: 09 April 2018 14:55 > > v2: > As suggested by Herbert Xu, the blocksize and alignmask checks > have been moved to crypto_check_alg. > So, now, all the other separate checks are not necessary. > Also, the defines have been moved to

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Mimi, On Mon, Apr 9, 2018 at 1:46 PM, Mimi Zohar wrote: > On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: >> Hi, >> >> I'm trying to get to the bottom of an issue I'm seeing when enabling >> the CAAM in the kernel with IMA/EVM enabled. I'm using the

Re: [PATCH 0/6] Remove several VLAs in the crypto subsystem

Please ignore this thread, I sent the old patch-set again by mistake :( I'm sorry for the noise. Salvatore

Re: [PATCH 3/6] crypto: api - avoid VLA use

2018-04-08 11:22 GMT+02:00 Herbert Xu : > On Sun, Apr 08, 2018 at 11:07:12AM +0200, Salvatore Mesoraca wrote: >> >> > This check should be done when the algorithm is registered. Perhaps >> > crypto_check_alg. >> >> Please correct me if I'm wrong: >> isn't

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

On Mon, 2018-04-09 at 09:41 +0100, Martin Townsend wrote: > Hi, > > I'm trying to get to the bottom of an issue I'm seeing when enabling > the CAAM in the kernel with IMA/EVM enabled. I'm using the official > NXP (imx_4.9.11_1.0.0_ga) vendor Kernel. > > Here's the error message I'm getting. >

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

On 04/03/2018 12:19 PM, Herbert Xu wrote: > On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote: >> However, as it uses the exact same mechanism of the regular xts-aes-ccree >> but takes the key from another source, I've marked it with a test of >> alg_test_null() on the premise that

Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation

On Sun, Apr 08, 2018 at 03:55:28PM -0700, Eric Biggers wrote: > On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote: > > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > > > From: Eric Biggers > > > > > > If the pcrypt template is used multiple times in

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

On Tue, Apr 3, 2018 at 3:22 PM, Milan Broz wrote: > On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote: > ... >>> Are there other crypto drivers doing this? >> >> I thought the exact same thing until I ran into a presentation about the s390 >> secure keys implementation. I

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

On Tue, Apr 3, 2018 at 1:19 PM, Herbert Xu wrote: > On Sat, Mar 31, 2018 at 08:30:46PM +0300, Gilad Ben-Yossef wrote: >> >> However, as it uses the exact same mechanism of the regular xts-aes-ccree >> but takes the key from another source, I've marked it with a test

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

On Mon, Apr 9, 2018 at 7:40 AM, Stephan Mueller wrote: > Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o: > > Hi Theodore, >> >> So the syzbot will run while the patch goes through the normal e-mail >> review process, which is kind of neat. :-) > > Thank you

Re: [PATCH] AF_ALG: register completely initialized request in list

Am Montag, 9. April 2018, 09:51:13 CEST schrieb Dmitry Vyukov: Hi Dmitry, > You can ask syzbot to test by replying to its report email with a test > command, see: > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication > -with-syzbot > > Note that all testing of KMSAN

Re: [PATCH] AF_ALG: register completely initialized request in list

On Sun, Apr 8, 2018 at 7:57 PM, Stephan Müller <smuel...@chronox.de> wrote: > Hi, > > May I ask to check whether this patch fixes the issue? I cannot re-create > the issue with the reproducter. Yet, as far as I understand, you try to > induce errors which shall validate w

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

Am Montag, 9. April 2018, 00:46:03 CEST schrieb Theodore Y. Ts'o: Hi Theodore, > > So the syzbot will run while the patch goes through the normal e-mail > review process, which is kind of neat. :-) Thank you very much for the hint. That is a neat feature indeed. As I came late to the party

Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation

On Fri, Mar 23, 2018 at 08:21:52AM +0800, Herbert Xu wrote: > On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > > From: Eric Biggers > > > > If the pcrypt template is used multiple times in an algorithm, then a > > deadlock occurs because all pcrypt instances

Re: INFO: task hung in exit_aio

[+Cc linux-crypto] On Sun, Dec 10, 2017 at 05:33:01AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 82bcf1def3b5f1251177ad47c44f7e17af039b4b > git://git.cmpxchg.org/linux-mmots.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

On Sun, Apr 08, 2018 at 09:07:03PM +0200, Stephan Müller wrote: > Can you please check whether the attached patch fixes the issue? > Stephan, FYI, if you incude in your e-mail "#syz test " as the first line of your patch and the syzbot e-mail is cc'ed, the syzbot will automatically apply the

Re: [RFC 0/2] add integrity and security to TPM2 transactions

On 3/5/2018 9:04 AM, Jason Gunthorpe wrote: On Fri, Mar 02, 2018 at 10:04:54PM -0800, James Bottomley wrote: By now, everybody knows we have a problem with the TPM2_RS_PW easy button on TPM2 in that transactions on the TPM bus can be intercepted and altered.  The way to fix this is to use real

Re: WARNING in kmem_cache_free

On Sun, Apr 8, 2018 at 5:31 PM, Stephan Müller wrote: > Am Sonntag, 8. April 2018, 13:18:06 CEST schrieb Dmitry Vyukov: > > Hi Dmitry, > >> >> Running syz-repro utility on this log, I think I've found the guilty guy: >>

Re: WARNING in kmem_cache_free

Am Sonntag, 8. April 2018, 13:18:06 CEST schrieb Dmitry Vyukov: Hi Dmitry, > > Running syz-repro utility on this log, I think I've found the guilty guy: > https://gist.githubusercontent.com/dvyukov/1dd75d55efd238e7207af1cc38478b3a/ > raw/403859b56b161a6fbb158e8953fac5bb6e73b1a1/gistfile1.txt >

Re: WARNING in kmem_cache_free

On Sun, Apr 8, 2018 at 12:26 PM, Dmitry Vyukov wrote: > On Sun, Apr 8, 2018 at 8:01 AM, Matthew Wilcox wrote: >> On Fri, Apr 06, 2018 at 03:33:36PM +0200, Dmitry Vyukov wrote: >>> On Fri, Apr 6, 2018 at 3:24 PM, syzbot >>>

Re: [PATCH 3/6] crypto: api - avoid VLA use

On Sun, Apr 08, 2018 at 11:07:12AM +0200, Salvatore Mesoraca wrote: > > > This check should be done when the algorithm is registered. Perhaps > > crypto_check_alg. > > Please correct me if I'm wrong: > isn't crypto_check_alg invoked also during hashing algorithm registration? > In this patch-set

Re: [PATCH 2/6] crypto: ctr - avoid VLA use

On Sun, Apr 08, 2018 at 10:58:48AM +0200, Salvatore Mesoraca wrote: > > Fair enough. > After removing the individual checks the modification to the single files > will be just a couple of lines, is it OK for you if I collapse all of them in > just a single commit? Sure. -- Email: Herbert Xu

Re: [PATCH 3/6] crypto: api - avoid VLA use

2018-04-08 5:16 GMT+02:00 Herbert Xu : > On Sat, Apr 07, 2018 at 08:38:20PM +0200, Salvatore Mesoraca wrote: >> >> int crypto_init_cipher_ops(struct crypto_tfm *tfm) >> { >> + const unsigned long alignmask = crypto_tfm_alg_alignmask(tfm); >> + const unsigned

Re: [PATCH 2/6] crypto: ctr - avoid VLA use

018-04-08 5:19 GMT+02:00 Herbert Xu : > On Sat, Apr 07, 2018 at 08:38:19PM +0200, Salvatore Mesoraca wrote: >> >> @@ -206,6 +207,14 @@ static struct crypto_instance *crypto_ctr_alloc(struct >> rtattr **tb) >> if (alg->cra_blocksize < 4) >> goto

Re: [PATCH 1/6] crypto: api - laying macros for statically allocated buffers

2018-04-08 5:15 GMT+02:00 Herbert Xu : > On Sat, Apr 07, 2018 at 08:38:18PM +0200, Salvatore Mesoraca wrote: >> Creating 2 new compile-time constants for internal use, >> in preparation for the removal of VLAs[1] from crypto code. >> All ciphers implemented in Linux

Re: [PATCH 0/6] Remove several VLAs in the crypto subsystem

2018-04-07 21:56 GMT+02:00 Kees Cook : > On Sat, Apr 7, 2018 at 11:38 AM, Salvatore Mesoraca > wrote: >> As suggested by Laura Abbott[2], I'm resending my patch with >> MAX_BLOCKSIZE and MAX_ALIGNMASK defined in an header, so they >> can be used in

Re: [PATCH 2/6] crypto: ctr - avoid VLA use

On Sat, Apr 07, 2018 at 08:38:19PM +0200, Salvatore Mesoraca wrote: > > @@ -206,6 +207,14 @@ static struct crypto_instance *crypto_ctr_alloc(struct > rtattr **tb) > if (alg->cra_blocksize < 4) > goto out_put_alg; > > + /* Block size must be <= MAX_BLOCKSIZE. */ > +

Re: [PATCH 3/6] crypto: api - avoid VLA use

On Sat, Apr 07, 2018 at 08:38:20PM +0200, Salvatore Mesoraca wrote: > > int crypto_init_cipher_ops(struct crypto_tfm *tfm) > { > + const unsigned long alignmask = crypto_tfm_alg_alignmask(tfm); > + const unsigned int size = crypto_tfm_alg_blocksize(tfm); > struct cipher_tfm *ops =

Re: [PATCH 1/6] crypto: api - laying macros for statically allocated buffers

On Sat, Apr 07, 2018 at 08:38:18PM +0200, Salvatore Mesoraca wrote: > Creating 2 new compile-time constants for internal use, > in preparation for the removal of VLAs[1] from crypto code. > All ciphers implemented in Linux have a block size less than or > equal to 16 bytes and the most demanding

Re: [PATCH 0/6] Remove several VLAs in the crypto subsystem

On Sat, Apr 7, 2018 at 11:38 AM, Salvatore Mesoraca wrote: > As suggested by Laura Abbott[2], I'm resending my patch with > MAX_BLOCKSIZE and MAX_ALIGNMASK defined in an header, so they > can be used in other places. > I take this opportuinuty to deal with some other VLAs

Re: [RESEND] SHASH_DESC_ON_STACK macro

Hi Herbert, On 03/27/2018 05:07 AM, Herbert Xu wrote: On Fri, Mar 23, 2018 at 02:09:46PM -0500, Gustavo A. R. Silva wrote: Hi Herbert, There is an ongoing effort to remove all VLAs from the code base [1] and while working on that I came across the following macro at

Re: [PATCH 1/2] crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK

On Wed, Mar 28, 2018 at 03:05:56PM +0200, Jan Glauber wrote: > Enabling virtual mapped kernel stacks breaks the thunderx_zip > driver. On compression or decompression the executing CPU hangs > in an endless loop. The reason for this is the usage of __pa > by the driver which does no longer work

Re: [PATCH v15 0/9] Add io{read|write}64 to io-64-atomic headers

Logan Gunthorpe writes: > On 4/4/2018 4:38 AM, Michael Ellerman wrote: ... >> eg. It looks like I could take the two powerpc patches on their own for >> 4.17, and then the rest could go via other trees? > > Yup! If you can take the powerpc patches I can keep trying to get the

Re: [PATCH v15 0/9] Add io{read|write}64 to io-64-atomic headers

On 4/4/2018 4:38 AM, Michael Ellerman wrote: What's the plan for getting it merged? Seems we don't have one? Yeah, so far there is no plan. I'm not really sure who's attention I need to get or how to get it. Given it touches two arches and generic stuff and drivers and crypto, it's a bit

Re: [PATCH v15 0/9] Add io{read|write}64 to io-64-atomic headers

Logan Gunthorpe writes: > This is v14 of my cleanup series to push a number of instances of people > defining their own io{read|write}64 functions into common headers seing > they don't exist in non-64bit systems. This series adds inline functions to > the > io-64-nonatomic

Re: [crypto-chtls] Supicious code in chtls_io

On 4/4/2018 3:16 AM, Gustavo A. R. Silva wrote: > Hi all, > > While doing some static analysis I came across the following piece of code at > drivers/crypto/chelsio/chtls/chtls_io.c:1203: > > 1203 if (!size) > 1204 break; > 1205 > 1206 if

Re: [v3] crypto: ctr - avoid VLA use

2018-04-03 23:37 GMT+02:00 Laura Abbott : > On 03/30/2018 01:53 AM, Salvatore Mesoraca wrote: >> --- >> crypto/ctr.c | 15 +-- >> 1 file changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/crypto/ctr.c b/crypto/ctr.c >> index 854d924..49c469d 100644 >>

Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.

On (04/03/18 19:13), Vaneet Narang wrote: > Hi Sergey, > > >You shrink a 2 bytes offset down to a 1 byte offset, thus you enforce that > 2 Byte offset is not shrinked to 1 byte, Its only 1 bit is reserved out of > 16 bits of offset. So only 15 Bits can be used to store offset value. Yes, you are

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