[ANNOUNCE] Linux Security Summit North America 2018 - CFP

== ANNOUNCEMENT AND CALL FOR PARTICIPATION LINUX SECURITY SUMMIT NORTH AMERICA 2018 27-28 August

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

[PATCH v2 1/5] crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK

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 for an address that is not part of the 1:1 mapping. The zip driver

[PATCH v2 0/5] ThunderX ZIP driver bug fixes

Some bug fixes for this driver after it stopped working with virtual mapped stacks. I think the first two patches qualify for stable. Jan Glauber (5): crypto: thunderx_zip: Fix fallout from CONFIG_VMAP_STACK crypto: thunderx_zip: Limit result reading attempts crypto: thunderx_zip: Prevent

[PATCH v2 5/5] crypto: thunderx_zip: Fix smp_processor_id() warnings

Switch to raw_smp_processor_id() to prevent a number of warnings from kernel debugging. We do not care about preemption here, as the CPU number is only used as a poor mans load balancing or device selection. If preemption happens during a compress/decompress operation a small performance hit will

[PATCH v2 4/5] crypto: thunderx_zip: Fix statistics pending request value

The pending request counter was read from the wrong register. While at it, there is no need to use an atomic for it as it is only read localy in a loop. Signed-off-by: Jan Glauber Reviewed-by: Robert Richter --- drivers/crypto/cavium/zip/zip_main.c |

[PATCH v2 3/5] crypto: thunderx_zip: Prevent division by zero

Avoid two potential divisions by zero when calculating average values for the zip statistics. Signed-off-by: Jan Glauber Reviewed-by: Robert Richter --- drivers/crypto/cavium/zip/zip_main.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-)

[PATCH v2 2/5] crypto: thunderx_zip: Limit result reading attempts

After issuing a request an endless loop was used to read the completion state from memory which is asynchronously updated by the ZIP coprocessor. Add an upper bound to the retry attempts to prevent a CPU getting stuck forever in case of an error. Additionally, add a read memory barrier and a

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

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

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 hw require 16 bytes alignment for the block buffer. [1]

[PATCH 6/6] crypto: cfb - avoid VLA use

We avoid 3 VLAs[1] by always allocating MAX_BLOCKSIZE bytes or, when needed for alignement, MAX_BLOCKSIZE + MAX_ALIGNMASK bytes. We also check the selected cipher at instance creation time, if it doesn't comply with these limits, the creation will fail. [1]

[PATCH 4/6] crypto: pcbc - avoid VLA use

We avoid 2 VLAs[1] by always allocating MAX_BLOCKSIZE bytes. We also check the selected cipher at instance creation time, if it doesn't comply with these limits, the creation will fail. [1] http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

[PATCH 5/6] crypto: cts - avoid VLA use

We avoid 2 VLAs[1] by always allocating MAX_BLOCKSIZE*2 bytes. We also check the selected cipher at instance creation time, if it doesn't comply with these limits, the creation will fail. [1] http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com

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

We avoid a VLA[1] by always allocating MAX_BLOCKSIZE + MAX_ALIGNMASK bytes. We also check the selected cipher at initialization time, if it doesn't comply with these limits, the initialization will fail. [1]

[PATCH v2 1/2] crypto: api - laying defines and checks for statically allocated buffers

In preparation for the removal of VLAs[1] from crypto code. We create 2 new compile-time constants: all ciphers implemented in Linux have a block size less than or equal to 16 bytes and the most demanding hw require 16 bytes alignment for the block buffer. We also enforce these limits in

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

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 include/crypto/algapi.h. v1: As suggested by Laura

[PATCH v2 2/2] crypto: remove several VLAs

We avoid various VLAs[1] by using constant expressions for block size and alignment mask. [1] http://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com Signed-off-by: Salvatore Mesoraca --- crypto/cfb.c| 7 +++ crypto/cipher.c

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

We avoid 2 VLAs[1] by always allocating MAX_BLOCKSIZE + MAX_ALIGNMASK bytes. We also check the selected cipher at instance creation time, if it doesn't comply with these limits, the creation will fail. [1]

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

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 not handled in the old patch. [1]

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

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

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. caam_jr 2142000.jr1: 4789: DECO: desc idx 7: Protocol Size Error - A

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 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 whether the error code