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

Hi Maninder, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.16-rc6] [cannot apply to next-20180322] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v6 03/12] PKCS#7: Introduce pkcs7_get_digest()

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > IMA will need to access the digest of the PKCS7 message (as calculated by > the kernel) before the signature is verified, so introduce > pkcs7_get_digest() for that purpose. > > Also, modify pkcs7_digest() to detect when the digest

Re: [PATCH v6 02/12] PKCS#7: Introduce pkcs7_get_message_sig() and verify_pkcs7_message_sig()

Hi Thiago, On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > IMA will need to know the key that signed a given PKCS#7 message, so add > pkcs7_get_message_sig(). > > It will also need to verify an already parsed PKCS#7 message. For this > purpose, add verify_pkcs7_message_sig()

Re: [PATCH v14 02/10] iomap: Add big endian sparse annotations to mmio_{read|write}XXbe()

On 3/22/2018 11:27 AM, Luc Van Oostenryck wrote: On Thu, Mar 22, 2018 at 11:16:55AM -0600, Logan Gunthorpe wrote: Sparse produces a few warnings of the form: lib/iomap.c:84:9: warning: cast to restricted __be16 (The kbuild robot has recently started running such checks) Reviewed-by: Luc Van

Re: [PATCH v14 02/10] iomap: Add big endian sparse annotations to mmio_{read|write}XXbe()

On Thu, Mar 22, 2018 at 11:16:55AM -0600, Logan Gunthorpe wrote: > Sparse produces a few warnings of the form: > > lib/iomap.c:84:9: warning: cast to restricted __be16 > > (The kbuild robot has recently started running such checks) Reviewed-by: Luc Van Oostenryck

Re: [PATCH 0/9] don't leak pointers to authenc keys

On Wed, Mar 21, 2018 at 07:00:48PM +0200, Tudor Ambarus wrote: > There are few places in crypto where we save pointers to the > authenc keys to a local variable of type struct crypto_authenc_keys > and we don't zeroize it after use. Fix all those cases and don't > leak pointers to the authenc

Re: [PATCH] crypto: talitos - fix IPsec cipher in length

Le 16/03/2018 à 15:07, Horia Geantă a écrit : On 3/16/2018 2:42 PM, Christophe LEROY wrote: Le 16/03/2018 à 09:48, Horia Geantă a écrit : For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using hardware ICV checking, the ICV length is provided via the

Re: [PATCH 7/9] crypto: picoxcell - don't leak pointers to authenc keys

On Wed, Mar 21, 2018 at 07:00:55PM +0200, Tudor Ambarus wrote: > Signed-off-by: Tudor Ambarus Reviewed-by: Jamie Iles > --- > drivers/crypto/picoxcell_crypto.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

Re: [PATCH 9/9] crypto: talitos - don't leak pointers to authenc keys

Le 21/03/2018 à 18:00, Tudor Ambarus a écrit : Signed-off-by: Tudor Ambarus Reviewed-by: Christophe Leroy --- drivers/crypto/talitos.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/talitos.c

Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo

Hi Philippe, > Actually to be consistent if you want to use GPL-2-0 (and not "or > later") you should use: > > 1. at the top, for a c. file: > // SPDX-License-Identifier: GPL-2.0 > > or for a .h file: > /* SPDX-License-Identifier: GPL-2.0 */ > > The doc explains it all. Including the comment

Re: [RESEND PATCH] crypto: Add zstd support

On (03/21/18 15:49), Nick Terrell wrote: > depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in Yikes! How come I missed that... :) > [0] > lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com Signed-off-by: Nick Terrell

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

ect that the patch > causes a regression in decompression speed for both LZ4 and LZ4_DYN. You'll > need to re-run the benchmarks to first show that LZ4 before the patch > performs the same as LZ4 after the patch. Then re-run the LZ4 vs LZ4_DYN > benchmarks. > > I would also like to

Re: [PATCH v6 07/12] integrity: Select CONFIG_KEYS instead of depending on it

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > This avoids a dependency cycle in CONFIG_IMA_APPRAISE_MODSIG (introduced by > a later patch in this series): it will select CONFIG_MODULE_SIG_FORMAT > which in turn selects CONFIG_KEYS. Kconfig then complains that >

Re: [PATCH v6 06/12] integrity: Introduce asymmetric_sig_has_known_key()

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > IMA will only look for a modsig if the xattr sig references a key which is > not in the expected kernel keyring. To that end, introduce > asymmetric_sig_has_known_key(). > > The logic of extracting the key used in the xattr sig is

Re: [PATCH v6 05/12] integrity: Introduce integrity_keyring_from_id()

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > IMA will need to obtain the keyring used to verify file signatures so that > it can verify the module-style signature appended to files. > > Signed-off-by: Thiago Jung Bauermann Signed-off-by: Mimi

Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo

Benjamin, On Wed, Mar 21, 2018 at 12:32 AM, Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> wrote: > Ok, I will use > > /* SPDX-License-Identifier: GPL-2.0 */ > /* > * Copyright (c) 2018 Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> > ... > > at the top of my files instead of that

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

On (03/21/18 10:10), Maninder Singh wrote: > diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c > index cc7b6d4..185c358 100644 > --- a/lib/lz4/lz4_compress.c > +++ b/lib/lz4/lz4_compress.c > @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic( > const tableType_t

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

Offset` variable isn't a compile time static in LZ4_decompress_generic(), I suspect that the patch causes a regression in decompression speed for both LZ4 and LZ4_DYN. You'll need to re-run the benchmarks to first show that LZ4 before the patch performs the same as LZ4 after the patch. Then re-run

Re: [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers

On 21/03/18 11:40 AM, Andy Shevchenko wrote: > The first patches that I didn't reviewed before makes sense to me, the > rest (at the end) FWIW, > > Reviewed-by: Andy Shevchenko Great, thanks! Logan

Re: [PATCH v13 00/10] Add io{read|write}64 to io-64-atomic headers

On Wed, Mar 21, 2018 at 6:37 PM, Logan Gunthorpe wrote: > > This is v13 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

Re: [PATCH v13 01/10] iomap: Use correct endian conversion function in mmio_writeXXbe

On Wed, Mar 21, 2018 at 10:37:36AM -0600, Logan Gunthorpe wrote: > The semantics of the iowriteXXbe() functions are to write a > value in CPU endianess to an IO register that is known by the > caller to be in Big Endian. The mmio_writeXXbe() macro, which > is called by iowriteXXbe(), should

Re: [PATCH] crypto: atmel-aes - fix the keys zeroing on errors

Hi Tudor, On Wed, Mar 21, 2018 at 03:15:27PM +0200, Tudor Ambarus wrote: > On 02/23/2018 02:37 PM, Antoine Tenart wrote: > > On Fri, Feb 23, 2018 at 02:04:33PM +0200, Tudor Ambarus wrote: > > > > > > There are few other places in crypto where we extract the authenc keys > > > in the same type of

Re: [PATCH] crypto: atmel-aes - fix the keys zeroing on errors

Hi, Antoine, On 02/23/2018 02:37 PM, Antoine Tenart wrote: Hi Tudor, On Fri, Feb 23, 2018 at 02:04:33PM +0200, Tudor Ambarus wrote: There are few other places in crypto where we extract the authenc keys in the same type of local variable, struct crypto_authenc_keys keys, and we don't zeroize

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

CC-ing Nick Nick, can you take a look? Message-IDs: lkml.kernel.org/r/1521607242-3968-1-git-send-email-maninder...@samsung.com lkml.kernel.org/r/1521607242-3968-2-git-send-email-maninder...@samsung.com -ss

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

On (03/21/18 10:10), Maninder Singh wrote: [..] > +static struct crypto_alg alg_lz4_dyn = { > + .cra_name = "lz4_dyn", > + .cra_flags = CRYPTO_ALG_TYPE_COMPRESS, > + .cra_ctxsize= sizeof(struct lz4_ctx), > + .cra_module =

Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo

Hi Philippe, > Am 20.03.2018 um 17:30 schrieb Philippe Ombredanne : > > Hi Benjamin, > > On Tue, Mar 20, 2018 at 7:04 AM, Benjamin Warnke > <4bwar...@informatik.uni-hamburg.de> wrote: >> zBeWalgo is a completely new algorithm - Currently it is not published >> somewhere

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

On (03/21/18 10:10), Maninder Singh wrote: > (Added cover letter to avoid much text in patch description) > > LZ4 specification defines 2 byte offset length for 64 KB data. > But in case of ZRAM we compress data per page and in most of > architecture PAGE_SIZE is 4KB. So we can decide offset

Re: [PATCH net-next 5/6] tls: RX path for ktls

On 3/20/2018 7:54 PM, Dave Watson wrote: Add rx path for tls software implementation. recvmsg, splice_read, and poll implemented. An additional sockopt TLS_RX is added, with the same interface as TLS_TX. Either TLX_RX or TLX_TX may be provided separately, or together (with two different

Re: [PATCH v12 net-next 12/12] crypto: chtls - Makefile Kconfig

Hi Atul, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on next-20180309] [also build test WARNING on v4.16-rc6] [cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

Re: [PATCH v12 net-next 01/12] tls: support for Inline tls record

Hi Atul, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on next-20180309] [also build test WARNING on v4.16-rc6] [cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo

Hi Benjamin, On Tue, Mar 20, 2018 at 7:04 AM, Benjamin Warnke <4bwar...@informatik.uni-hamburg.de> wrote: > zBeWalgo is a completely new algorithm - Currently it is not published > somewhere else right now, googleing it would not show up any results. The > following section describes how the

Re: [PATCH v12 net-next 12/12] crypto: chtls - Makefile Kconfig

Hi Atul, Thank you for the patch! Yet something to improve: [auto build test ERROR on next-20180309] [also build test ERROR on v4.16-rc6] [cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2] crypto: doc - clarify hash callbacks state machine

On 3/20/2018 10:50 AM, Kamil Konieczny wrote: > On 20.03.2018 08:56, Horia Geantă wrote: >> Add a note that it is perfectly legal to "abandon" a request object: >> - call .init() and then (as many times) .update() >> - _not_ call any of .final(), .finup() or .export() at any point in >> future

Re: [PATCH v2] crypto: doc - clarify hash callbacks state machine

On 20.03.2018 08:56, Horia Geantă wrote: > Add a note that it is perfectly legal to "abandon" a request object: > - call .init() and then (as many times) .update() > - _not_ call any of .final(), .finup() or .export() at any point in > future > > Link:

Re: [PATCH v5 00/23] crypto: arm64 - play nice with CONFIG_PREEMPT

On Mon, Mar 19, 2018 at 11:31:24PM +0800, Ard Biesheuvel wrote: > > Apologies if this wasn't clear, but there are some cross dependencies > with the arm64 tree, which receives non-trivial modifications in > patches 10 and 11, which are subsequently depended upon by patches 12 > - 23. > > Without

Re: [PATCH] crypto: doc - clarify hash callbacks state machine

On Mon, Mar 19, 2018 at 11:04:24AM +, Horia Geantă wrote: > > The only solution to avoid leaks in this case is to repeatedly DMA map & unmap > the buffer. > IOW, if one wants to load/save HW state in a buffer after an .update() and to > instruct the crypto engine to do this operation, the

Re: [PATCH v12 1/9] iomap: Fix sparse endian check warnings

Hi Luc, Thanks for the feedback. I'll try to address your points in a v13 shortly. Logan On 18/03/18 10:13 AM, Luc Van Oostenryck wrote: > it looks correct but if you should explain why the warning > is not a valid one. Once done, you can then explain what problem > you have fixed instead of

Re: [PATCH v12 net-next 06/12] crypto: chtls - structure and macro for Inline TLS

t; + > + if (!sock_flag(sk, SOCK_INLINE)) > + return 0; Please take care of the comments. I understand this series is big and you might be tempted to minimize your effort in the hope that reviewers will fail to check that you addressed their concerns. You are also succeedin

Re: [PATCH v12 net-next 10/12] crypto: chtls - Inline TLS record Rx

On Mon, 19 Mar 2018 19:25:43 +0530 Atul Gupta wrote: > +int chtls_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, > + int nonblock, int flags, int *addr_len) > +{ > > [...] > > + if (likely(!(flags & MSG_TRUNC))) { > +

Re: [PATCH v12 net-next 01/12] tls: support for Inline tls record

On Mon, 19 Mar 2018 19:25:34 +0530 Atul Gupta wrote: > @@ -268,6 +259,8 @@ static void tls_sk_proto_close(struct sock *sk, long > timeout) > skip_tx_cleanup: > release_sock(sk); > sk_proto_close(sk, timeout); > + if (ctx && ctx->tx_conf == TLS_HW_RECORD)

Re: [PATCH v12 net-next 09/12] crypto: chtls - Inline TLS record Tx

On Mon, 19 Mar 2018 19:25:42 +0530 Atul Gupta wrote: > +static bool is_tls_skb(struct chtls_sock *csk, const struct sk_buff *skb) > +{ > + return skb_ulp_tls_skb_flags(skb); > +} Do you need this function? > +/* Copy Key to WR */ > +static void

Re: [PATCH v12 net-next 00/12] Chelsio Inline TLS

On Mon, 19 Mar 2018 19:25:33 +0530 Atul Gupta wrote: > Series for Chelsio Inline TLS driver (chtls) > > [...] > > v12: patch against net-next > - fixed few build error > - replace set_queue with skb_set_queue_mapping [Sabrina] > - copyright year correction

Re: [PATCH v5 00/23] crypto: arm64 - play nice with CONFIG_PREEMPT

On 16 March 2018 at 23:57, Herbert Xu wrote: > On Sat, Mar 10, 2018 at 03:21:45PM +, Ard Biesheuvel wrote: >> As reported by Sebastian, the way the arm64 NEON crypto code currently >> keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is >>

Re: [PATCH] crypto: doc - clarify hash callbacks state machine

On 3/19/2018 11:25 AM, Herbert Xu wrote: > On Mon, Mar 19, 2018 at 06:39:50AM +, Horia Geantă wrote: >> >> The fact that there can be multiple requests in parallel (for a given tfm) >> is a >> different topic. >> Each request object has its state in its own state machine, independent from >>

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

On 3/19/2018 2:52 PM, Herbert Xu wrote: > On Sun, Mar 18, 2018 at 10:36:02AM -0400, David Miller wrote: >> Herbert, is it OK for this entire series to go via net-next? > Sure, although there could be conflicts since the chelsio driver > seems to be changing quite fast. I applied chcr patches

Re: [PATCH] crypto: doc - clarify hash callbacks state machine

On Mon, Mar 19, 2018 at 06:39:50AM +, Horia Geantă wrote: > > The fact that there can be multiple requests in parallel (for a given tfm) is > a > different topic. > Each request object has its state in its own state machine, independent from > the > other request objects. > I assume this is

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

On Sun, Mar 18, 2018 at 10:36:02AM -0400, David Miller wrote: > > Herbert, is it OK for this entire series to go via net-next? Sure, although there could be conflicts since the chelsio driver seems to be changing quite fast. Cheers, -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto: doc - clarify hash callbacks state machine

On 3/16/2018 5:16 PM, Herbert Xu wrote: > On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote: >> Even though it doesn't make too much sense, it is perfectly legal to: >> - call .init() and then (as many times) .update() >> - subseqently _not_ call any of .final(), .finup() or .export() >

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

On 3/18/2018 8:06 PM, David Miller wrote: > From: Atul Gupta > Date: Sun, 18 Mar 2018 14:30:30 + > >> Hi Dave/Herbert, >> >> This series is against crypto tree, should I submit two patch series: >> 1. netdev specific changes against net-next tree? >> 2. crypto

Re: [PATCH v11 crypto 06/12] crypto: chtls - structure and macro for Inline TLS

sk = rcu_dereference_sk_user_data(sk); >> + >> +if (!sock_flag(sk, SOCK_INLINE)) >> +return 0; >> +return test_bit(flag, >flags); >> +} > Should drivers really start defining their own socket flags? this is for conn in Inline mode once transitioned to

Re: [PATCH v11 crypto 06/12] crypto: chtls - structure and macro for Inline TLS

2018-03-16, 21:07:35 +0530, Atul Gupta wrote: [...] > +#define SOCK_INLINE (31) [...] > +static inline int csk_flag(const struct sock *sk, enum csk_flags flag) > +{ > + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk); > + > + if (!sock_flag(sk, SOCK_INLINE)) > +

Re: [PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency

On 03/16/2018 02:51 PM, Geert Uytterhoeven wrote: Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols

Re: [PATCH v12 1/9] iomap: Fix sparse endian check warnings

On Fri, Mar 16, 2018 at 09:48:44AM -0600, Logan Gunthorpe wrote: > Warnings of the form: > > lib/iomap.c:84:9: warning: cast to restricted __be16 > > Are found when running sparse checker with: > > make C=2 CF=-D__CHECK_ENDIAN__ > > This patch casts them with __force to suppress the warnings.

Re: [PATCH v11 crypto 01/12] tls: support for Inline tls record (fwd)

ctx is dereferenced on line 258 but has been freed on line 229. julia -- Forwarded message -- Date: Sun, 18 Mar 2018 18:05:25 +0800 From: kbuild test robot <fengguang...@intel.com> To: kbu...@01.org Cc: Julia Lawall <julia.law...@lip6.fr> Subject: Re: [PATCH v11

Re: [PATCH v11 crypto 12/12] crypto: chtls - Makefile Kconfig (fwd)

Please check the indentation on line 1655. thanks, julia -- Forwarded message -- Date: Sun, 18 Mar 2018 18:15:36 +0800 From: kbuild test robot <fengguang...@intel.com> To: kbu...@01.org Cc: Julia Lawall <julia.law...@lip6.fr> Subject: Re: [PATCH v11 crypto 12/12] c

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

From: Atul Gupta Date: Sun, 18 Mar 2018 14:30:30 + > Hi Dave/Herbert, > > This series is against crypto tree, should I submit two patch series: > 1. netdev specific changes against net-next tree? > 2. crypto changes against crypto tree? Herbert, is it OK for this

RE: [PATCH v11 crypto 00/12] Chelsio Inline TLS

:33 AM To: Atul Gupta <atul.gu...@chelsio.com> Cc: davejwat...@fb.com; herb...@gondor.apana.org.au; s...@queasysnail.net; sbri...@redhat.com; linux-crypto@vger.kernel.org; net...@vger.kernel.org; Ganesh GR <ganes...@chelsio.com> Subject: Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

Re: [PATCH v11 crypto 00/12] Chelsio Inline TLS

From: Atul Gupta Date: Fri, 16 Mar 2018 21:06:22 +0530 > Series for Chelsio Inline TLS driver (chtls) This series doesn't even come close to applying to the net-next tree, please respin. Thank you.

Re: [PATCH 11/12] crypto: inside-secure - hmac(sha256) support

Hi Antoine, I love your patch! Yet something to improve: [auto build test ERROR on next-20180309] [cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2 v4.16-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v6 00/12] Appended signatures support for IMA appraisal

Thiago Jung Bauermann writes: > Now the modsig is only ignored if it references a signature that is not > present in IMA's keyring (or if there's a parsing error, obviously). If the The above should read "Now the modsig is only ignored if it references a *key* that

Re: [PATCH][next] crypto: x86/des3_ede: make array des3_ede_skciphers static

On Mon, Mar 05, 2018 at 02:18:00PM +0100, Colin King wrote: > From: Colin Ian King > > The array des3_ede_skciphers is local to the source and does not need > to be in global scope, so make it static. > > Cleans up sparse warning: >

Re: [PATCH v5 00/23] crypto: arm64 - play nice with CONFIG_PREEMPT

On Sat, Mar 10, 2018 at 03:21:45PM +, Ard Biesheuvel wrote: > As reported by Sebastian, the way the arm64 NEON crypto code currently > keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is > causing problems with RT builds, given that the skcipher walk API may > allocate and

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

On Thu, Mar 08, 2018 at 01:57:02PM -0800, Kees Cook wrote: > On the quest to remove all VLAs from the kernel[1], this switches to > a pair of kmalloc regions instead of using the stack. This also moves > the get_random_bytes() after all allocations (and drops the needless > "nbytes" variable). >

Re: [PATCH] crypto: virtio - remove dependency on CRYPTO_AUTHENC

On Wed, Mar 07, 2018 at 12:53:15AM +0100, Peter Wu wrote: > virtio_crypto does not use function crypto_authenc_extractkeys, remove > this unnecessary dependency. Compiles fine and passes cryptodev-linux > cipher and speed tests from https://wiki.qemu.org/Features/VirtioCrypto > > Fixes:

Re: [PATCH] crypto: ccp: Use memdup_user() rather than duplicating its implementation

On Mon, Mar 05, 2018 at 02:10:20PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 5 Mar 2018 13:50:13 +0100 > > Reuse existing functionality from memdup_user() instead of keeping > duplicate source code. > > This issue was detected by using

Re: [PATCH v2] crypto: hash.h: Prevent use of req->result in ahash update

On Wed, Mar 07, 2018 at 11:49:33AM +0100, Kamil Konieczny wrote: > Prevent improper use of req->result field in ahash update, init, export and > import functions in drivers code. A driver should use ahash request context > if it needs to save internal state. > > Signed-off-by: Kamil Konieczny

Re: [PATCH] crypto/ccp: Validate buffer lengths for copy operations

On Wed, Mar 07, 2018 at 11:31:14AM -0600, Gary R Hook wrote: > The CCP driver copies data between scatter/gather lists and DMA buffers. > The length of the requested copy operation must be checked against > the available destination buffer length. > > Reported-by: Maciej S. Szmigiero

Re: [PATCH 0/2] crypto: introduce SM4 symmetric cipher algorithm

On Tue, Mar 06, 2018 at 09:44:41AM +, Gilad Ben-Yossef wrote: > Introduce the SM4 cipher algorithms (OSCCA GB/T 32907-2016) and > related tests. > > SM4 (GBT.32907-2016) is a cryptographic standard issued by the > Organization of State Commercial Administration of China (OSCCA) > as an

Re: [PATCH v2 0/5] crypto:chelsio: Bug fixes and cleanup

On Tue, Mar 06, 2018 at 10:37:47AM +0530, Harsh Jain wrote: > It includes bug fixes and code cleanup. > > Changes from v1: > > Remove Redundant soffset initialisation from 2/5. > > Harsh Jain (5): > crypto:chelsio: Use kernel round function to align lengths > crypto:chelsio: Fix src buffer

Re: [PATCH v2 0/2] hwrng: mxc-rnga - add driver support on boards with device tree

On Tue, Mar 06, 2018 at 12:20:58AM +0200, Vladimir Zapolskiy wrote: > The series is a trivial change to extend Freescale i.MX31 RNGA > driver to work on boards with device description taken from device > tree blob. The change was tested on a legacy LogicPD MX31Lite board. > > Vladimir Zapolskiy

Re: [RFC PATCH] crypto: arm64/speck - add NEON-accelerated implementation of Speck-XTS

On Mon, Mar 05, 2018 at 11:17:07AM -0800, Eric Biggers wrote: > Add a NEON-accelerated implementation of Speck128-XTS and Speck64-XTS > for ARM64. This is ported from the 32-bit version. It may be useful on > devices with 64-bit ARM CPUs that don't have the Cryptography > Extensions, so cannot

Re: [PATCH] crypto: doc - clarify hash callbacks state machine

On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote: > Even though it doesn't make too much sense, it is perfectly legal to: > - call .init() and then (as many times) .update() > - subseqently _not_ call any of .final(), .finup() or .export() Actually it makes perfect sense, because

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

On Thu, Jan 18, 2018 at 04:44:21PM -0800, Megha Dey wrote: > > > So the mcryptd template is in fact completely superfluous. You > > can remove it and just have all the main encrypt/decrypt functions > > invoke the underlying encrypt/decrypt function directly and achieve > > the same result. > >

Re: [PATCH v2 17/21] scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency

On 16/03/2018 13:51, Geert Uytterhoeven wrote: Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and

Re: [PATCH] crypto: talitos - fix IPsec cipher in length

On 3/16/2018 2:42 PM, Christophe LEROY wrote: > Le 16/03/2018 à 09:48, Horia Geantă a écrit : >> For SEC 2.x+, cipher in length must contain only the ciphertext length. >> In case of using hardware ICV checking, the ICV length is provided via >> the "extent" field of the descriptor pointer. >> >>

Re: [PATCH v3 0/6] add integrity and security to TPM2 transactions

On Mon, Mar 12, 2018 at 08:57:13AM -0700, James Bottomley wrote: > I think the way I'm going to fix the trusted key policy problem is to > move it back into the kernel for the simple PCR lock policy (which will > make changing from 1.2 to 2.0 seamless because the external Key API > will then

Re: [PATCH] crypto: talitos - fix IPsec cipher in length

Le 16/03/2018 à 09:48, Horia Geantă a écrit : For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using hardware ICV checking, the ICV length is provided via the "extent" field of the descriptor pointer. Cc: # 4.8+ Fixes: 549bd8bc5987

Re: [PATCH v3 1/6] tpm-buf: create new functions for handling TPM buffers

On Fri, 2018-03-16 at 13:58 +0200, Jarkko Sakkinen wrote: > On Sat, 2018-03-10 at 14:14 -0800, James Bottomley wrote: > > TPM_BUF_OVERFLOW= BIT(0), > > + TPM_BUF_2B = BIT(1), > > Instead of re-using this I would prefer to have another e

Re: [PATCH v3 1/6] tpm-buf: create new functions for handling TPM buffers

On Sat, 2018-03-10 at 14:14 -0800, James Bottomley wrote: > TPM_BUF_OVERFLOW= BIT(0), > + TPM_BUF_2B = BIT(1), Instead of re-using this I would prefer to have another enum for buffer type. tpm_buf_init() could have the signature: int tpm_buf_init(unsigned in

Re: [PATCH 00/12] crypto: inside-secure - hmac(sha256/sha224) support

On Thu, Mar 15, 2018 at 04:45:54PM +0100, Antoine Tenart wrote: > > I made a small mistake as the first 3 patches of the series already > were merged into your tree, as they already were sent in a previous > series. You can just ignore them. OK. Thanks, -- Email: Herbert Xu

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

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 share the same > padata_instance, which completes requests in the order

Re: [PATCH 00/12] crypto: inside-secure - hmac(sha256/sha224) support

Hi Herbert, On Thu, Mar 15, 2018 at 04:38:39PM +0100, Antoine Tenart wrote: > > This series brings hmac(sha256) and hmac(sha224) support to the Inside > Secure cryptographic engine driver. > > The first 10 patches are fixes and reworks needed for the hmac(sha256) > and hmac(224) support to land

Re: [Blackfin removal] [PATCH 18/28] crypto: Remove Blackfin crypto support

On Thu, Mar 15, 2018 at 03:49:33PM +0100, Arnd Bergmann wrote: > On Thu, Mar 15, 2018 at 11:50 AM, Aaron Wu wrote: > > Signed-off-by: Aaron Wu > > > > Remove Blackfin crypto support > > --- > > crypto/testmgr.c | 6 - > > crypto/testmgr.h

Re: [Blackfin removal] [PATCH 18/28] crypto: Remove Blackfin crypto support

On Thu, Mar 15, 2018 at 11:50 AM, Aaron Wu wrote: > Signed-off-by: Aaron Wu > > Remove Blackfin crypto support > --- > crypto/testmgr.c | 6 - > crypto/testmgr.h | 88 -- I'm not sure about this one: while the function name

Re: [PATCH] crypto: ctr: avoid VLA use

Hi Salvatore, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180314] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

RE: [PATCH] crypto: ctr: avoid VLA use

From: Eric Biggers > Sent: 14 March 2018 18:32 ... > Also, I recall there being a long discussion a while back about how > __aligned(16) doesn't work on local variables because the kernel's stack > pointer > isn't guaranteed to maintain the alignment assumed by the compiler (see commit >

Re: [PATCH] crypto: ctr: avoid VLA use

2018-03-15 10:54 GMT+01:00 Herbert Xu : > On Wed, Mar 14, 2018 at 02:17:30PM +0100, Salvatore Mesoraca wrote: >> All ciphers implemented in Linux have a block size less than or >> equal to 16 bytes and the most demanding hw require 16 bits >> alignment for the block

Re: [PATCH] crypto: ctr: avoid VLA use

On Wed, Mar 14, 2018 at 02:17:30PM +0100, Salvatore Mesoraca wrote: > All ciphers implemented in Linux have a block size less than or > equal to 16 bytes and the most demanding hw require 16 bits > alignment for the block buffer. > We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bits >

Re: [PATCH 00/47] arch-removal: device drivers

Hi Arnd, On Wed, 14 Mar 2018 16:35:13 +0100 Arnd Bergmann wrote: > Hi driver maintainers, > > I just posted one series with the removal of eight architectures, > see https://lkml.org/lkml/2018/3/14/505 for details, or > https://lwn.net/Articles/748074/ for more background. > >

Re: Official Notice

This email just won a sum of €5,000,000. For claims, Send your NAME, AGE & TELEPHONE NUMBER to: mastercard-awa...@columbus.rr.com

Re: [PATCH] crypto: ctr: avoid VLA use

2018-03-14 19:31 GMT+01:00 Eric Biggers : > On Wed, Mar 14, 2018 at 02:17:30PM +0100, Salvatore Mesoraca wrote: >> All ciphers implemented in Linux have a block size less than or >> equal to 16 bytes and the most demanding hw require 16 bits >> alignment for the block buffer.

Re: [PATCH] crypto: ctr: avoid VLA use

On Wed, Mar 14, 2018 at 02:17:30PM +0100, Salvatore Mesoraca wrote: > All ciphers implemented in Linux have a block size less than or > equal to 16 bytes and the most demanding hw require 16 bits > alignment for the block buffer. > We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bits >

Re: [PATCH] crypto: ctr: avoid VLA use

Am Mittwoch, 14. März 2018, 14:46:29 CET schrieb Salvatore Mesoraca: Hi Salvatore, > 2018-03-14 14:31 GMT+01:00 Stephan Mueller : > > Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca: > > > > Hi Salvatore, > > > >> if (walk.nbytes) { > >> > >> -

Re: [PATCH] crypto: ctr: avoid VLA use

2018-03-14 14:31 GMT+01:00 Stephan Mueller : > Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca: > > Hi Salvatore, > >> if (walk.nbytes) { >> - crypto_ctr_crypt_final(, child); >> - err = blkcipher_walk_done(desc, , 0); >> +

Re: [PATCH] crypto: ctr: avoid VLA use

Am Mittwoch, 14. März 2018, 14:17:30 CET schrieb Salvatore Mesoraca: Hi Salvatore, > if (walk.nbytes) { > - crypto_ctr_crypt_final(, child); > - err = blkcipher_walk_done(desc, , 0); > + err = crypto_ctr_crypt_final(, child); > + err =

Re: [PATCH] crypto: arm,arm64 - Fix random regeneration of S_shipped

On 14 March 2018 at 02:31, Masahiro Yamada wrote: > 2018-03-14 5:17 GMT+09:00 Leonard Crestez : >> The decision to rebuild .S_shipped is made based on the relative >> timestamps of .S_shipped and .pl files but git makes this essentially >>

Re: [PATCH] crypto: arm,arm64 - Fix random regeneration of S_shipped

2018-03-14 5:17 GMT+09:00 Leonard Crestez : > The decision to rebuild .S_shipped is made based on the relative > timestamps of .S_shipped and .pl files but git makes this essentially > random. This means that the perl script might run anyway (usually at > most once per

Re: [PATCH v3 1/6] tpm-buf: create new functions for handling TPM buffers

On 3/12/18 10:59 AM, James Bottomley wrote: On Mon, 2018-03-12 at 09:00 -0700, J Freyensee wrote: +int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal) +{ + int rc; + + rc = __tpm_buf_init(buf); Assuming that functions like tpm_buf_init() are the top-level API being

Re: [PATCH -next] crypto: fix missing unlock on error in safexcel_ahash_send_req()

Hi Wei, On Tue, Mar 13, 2018 at 02:54:03PM +, Wei Yongjun wrote: > Add the missing unlock before return from function > safexcel_ahash_send_req() in the error handling case. > > Fixes: cff9a17545a3 ("crypto: inside-secure - move cache result dma mapping > to request") > Signed-off-by: Wei

Re: [EXTERNAL] Re: what is a replacement for private_AES_set_encrypt_key and AES_encrypt functions

On 03/12/2018 10:43 AM, Ard Biesheuvel wrote: On 12 March 2018 at 14:38, Vitaly Andrianov wrote: Hello, The Texas Instruments keystone2 out-of-tree kernel uses the private_AES_set_encrypt_key() and the AES_encrypt() at the crypto HW acceleration driver. The "crypto: arm/aes -

<    4   5   6   7   8   9   10   11   12   13   >