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

On 03/30/2018 01:53 AM, 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 bytes alignment for the block buffer. We avoid 2 VLAs[1] by always allocating 16 bytes with 16 bytes alignment, unless the

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

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. >'page should be less than 32KB', which I'm sure will be

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

On (04/02/18 11:21), Maninder Singh wrote: [..] > >> static const char * const backends[] = { > >> "lzo", > >> #if IS_ENABLED(CONFIG_CRYPTO_LZ4) > >> "lz4", > >> +#if (PAGE_SIZE < (32 * KB)) > >> +"lz4_dyn", > >> +#endif > > > >This is not the list of supported

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

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 basically imitated their use (or abuse?) > of the Crypto API > assuming it is the way

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

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 if the xts-aes-ccree works, so must this.

Re: [PATCH] crypto: rsa - remove unneeded initializations

On Tue, Apr 03, 2018 at 09:01:02AM +0300, Tudor Ambarus wrote: > > I set the err inside the if branch so that the compiler will > warn me in case of undefined value for err. Like here: > > https://rusty.ozlabs.org/?p=232 Yes but then sometimes the compiler will get it wrong and we will then have

Re: [PATCH] crypto: rsa - remove unneeded initializations

On 03/30/2018 08:27 PM, Herbert Xu wrote: On Mon, Mar 26, 2018 at 02:59:06PM +0300, Tudor Ambarus wrote: Remove useless assignment of ret to -ENOMEM in rsa_verify. Remove useless initialization of ret to zero at declaration in rsa_enc/dec/sign/verify. Benefit of the power of undefined values

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

 Hello, >> (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 length based >> on actual offset

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

Hi, >> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c >> index 4ed0a78..5bc5aab 100644 >> --- a/drivers/block/zram/zcomp.c >> +++ b/drivers/block/zram/zcomp.c >> @@ -17,11 +17,15 @@ >> #include >> >> #include "zcomp.h" >> +#define KB(1 << 10) >> >> static

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

On 3/31/2018 7:11 PM, Atul Gupta wrote: Facility to register Inline TLS drivers to net/tls. Setup TLS_HW_RECORD prot to listen on offload device. Cases handled - Inline TLS device exists, setup prot for TLS_HW_RECORD - Atleast one Inline TLS exists, sets TLS_HW_RECORD. - If non-inline device

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

Hi, On 4/1/2018 6:37 AM, David Miller wrote: From: Atul Gupta Date: Sat, 31 Mar 2018 21:41:51 +0530 Series for Chelsio Inline TLS driver (chtls) Series applied, thank you. Sorry for being late to the party, could you please help answer a few questions to help me

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

From: Atul Gupta Date: Sat, 31 Mar 2018 21:41:51 +0530 > Series for Chelsio Inline TLS driver (chtls) Series applied, thank you.

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

On Fri, Mar 30, 2018 at 8:26 PM, Herbert Xu wrote: > On Mon, Mar 26, 2018 at 08:32:19AM +0100, Gilad Ben-Yossef wrote: >> Enable CryptoCell support for hardware keys. >> >> Hardware keys are regular AES keys loaded into CryptoCell internal memory >> via firmware,

Re: [Cocci] [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Sat, 31 Mar 2018, Varsha Rao wrote: > On Sat, Mar 31, 2018 at 11:48 AM, Julia Lawall wrote: > > On Thu, 29 Mar 2018, Varsha Rao wrote: > > > >> On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > >> > > >> > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > >> > > This patch fixes the

Re: [Cocci] [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Sat, Mar 31, 2018 at 11:48 AM, Julia Lawall wrote: > On Thu, 29 Mar 2018, Varsha Rao wrote: > >> On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: >> > >> > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: >> > > This patch fixes the clang warning of extraneous parentheses, with the >> > >

Re: [Cocci] [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Thu, 29 Mar 2018, Varsha Rao wrote: > On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > > This patch fixes the clang warning of extraneous parentheses, with the > > > following coccinelle script. > > > > > > @@ > > > identifier i;

Re: [Cocci] [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Fri, 30 Mar 2018, Joe Perches wrote: > On Thu, 2018-03-29 at 21:03 +0530, Varsha Rao wrote: > > On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > > > > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > > > This patch fixes the clang warning of extraneous parentheses, with the > > >

Re: [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Thu, 2018-03-29 at 21:03 +0530, Varsha Rao wrote: > On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > > This patch fixes the clang warning of extraneous parentheses, with the > > > following coccinelle script. > > > > > > @@ > > >

Re: [RESEND PATCH] crypto: Add zstd support

> On Mar 30, 2018, at 10:14 AM, Herbert Xu wrote: > > On Thu, Mar 22, 2018 at 01:32:30PM +0900, Sergey Senozhatsky wrote: >> 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

Re: [PATCH 1/2] crypto: ccree: remove unused enums

On Mon, Mar 26, 2018 at 08:32:18AM +0100, Gilad Ben-Yossef wrote: > Remove enums definitions unused in the driver code. > > Signed-off-by: Gilad Ben-Yossef Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [RFC PATCH] crypto: brcm - explicitly cast cipher to hash type

On Sat, Mar 24, 2018 at 12:02:42PM +0100, Stefan Agner wrote: > In the AES cases enum spu_cipher_type and enum hash_type have > the same values, so the assignment is fine. Explicitly cast > the enum type conversion. > > This fixes two warnings when building with clang: >

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

On Fri, Mar 23, 2018 at 12:42:15PM +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 v1] crypto: Deduplicate le32_to_cpu_array() and cpu_to_le32_array()

On Wed, Mar 21, 2018 at 07:01:40PM +0200, Andy Shevchenko wrote: > Deduplicate le32_to_cpu_array() and cpu_to_le32_array() by moving them > to the generic header. > > No functional change implied. > > Signed-off-by: Andy Shevchenko Patch applied. Thanks. --

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

On Thu, Mar 22, 2018 at 10:57:01AM +0100, Christophe Leroy wrote: > 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: #

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

On Tue, Mar 20, 2018 at 09:56:12AM +0200, 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 v2 0/9] crypto: inside-secure - hmac(sha256/sha224) support

On Mon, Mar 19, 2018 at 09:21:12AM +0100, Antoine Tenart wrote: > Hi Herbert, > > This series brings hmac(sha256) and hmac(sha224) support to the Inside > Secure cryptographic engine driver. > > The first 7 patches are fixes and reworks needed for the hmac(sha256) > and hmac(224) support to land

Re: [PATCH 1/1] crypto:chelsio - Remove declaration of static function from header

On Mon, Mar 19, 2018 at 07:06:22PM +0530, Harsh Jain wrote: > It fixes compilation warning introduced in commit > > Introduced by commit > > 5110e65536f3 ("crypto: chelsio -Split Hash requests for large scatter > gather list") > > Reported-by: Stephen Rothwell >

Re: [PATCH] crypto: rsa - remove unneeded initializations

On Mon, Mar 26, 2018 at 02:59:06PM +0300, Tudor Ambarus wrote: > Remove useless assignment of ret to -ENOMEM in rsa_verify. > Remove useless initialization of ret to zero at declaration in > rsa_enc/dec/sign/verify. > > Benefit of the power of undefined values and set ret in branches in >

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

On Mon, Mar 26, 2018 at 08:32:19AM +0100, Gilad Ben-Yossef wrote: > Enable CryptoCell support for hardware keys. > > Hardware keys are regular AES keys loaded into CryptoCell internal memory > via firmware, often from secure boot ROM or hardware fuses at boot time. > > As such, they can be used

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

On Fri, Mar 23, 2018 at 12:42:16PM +0200, Tudor Ambarus wrote: > In crypto_authenc_setkey we save pointers to the authenc keys in > a local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > > Signed-off-by:

Re: [PATCH] omap-crypto - fix kernel oops and output buffer update

Francis Le Bourse wrote: > Hi Tero, > >> I have a couple of additional comments, but can't add them as the patch >> content is an attachment (like, I would not add the WARN_ON.) Overall, >> the issue you have found is a legitimate problem, and should be fixed. > > I

Re: [RESEND PATCH] crypto: Add zstd support

On Thu, Mar 22, 2018 at 01:32:30PM +0900, Sergey Senozhatsky wrote: > 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] > >

Re: [PATCH v14 net-next 08/12] crypto : chtls - CPL handler definition

On Friday, March 03/30/18, 2018 at 00:38:06 +0530, Atul Gupta wrote: > > > On 3/29/2018 9:56 PM, Sabrina Dubroca wrote: > > 2018-03-29, 21:27:50 +0530, Atul Gupta wrote: > > ... > >> +static void chtls_pass_accept_request(struct sock *sk, > >> +struct sk_buff

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

On (03/29/18 15:56), Maninder Singh wrote: > Hello Nick/Sergey, > > Any suggestion or comments, so that we can change code and resend the patch? Well... there were no replies to https://marc.info/?l=linux-kernel=152161450026771=2 and https://marc.info/?l=linux-kernel=152161860627974=2

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

On 3/29/2018 9:56 PM, Sabrina Dubroca wrote: > 2018-03-29, 21:27:51 +0530, Atul Gupta wrote: >> TLS handler for record transmit. >> Create Inline TLS work request and post to FW. >> Create Inline TLS record CPLs for hardware >> >> Signed-off-by: Atul Gupta >>

Re: [PATCH v14 net-next 08/12] crypto : chtls - CPL handler definition

On 3/29/2018 9:56 PM, Sabrina Dubroca wrote: > 2018-03-29, 21:27:50 +0530, Atul Gupta wrote: > ... >> +static void chtls_pass_accept_request(struct sock *sk, >> + struct sk_buff *skb) >> +{ > ... >> +if (chtls_get_module(newsk)) >> +goto reject;

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

2018-03-29, 21:27:51 +0530, Atul Gupta wrote: > TLS handler for record transmit. > Create Inline TLS work request and post to FW. > Create Inline TLS record CPLs for hardware > > Signed-off-by: Atul Gupta > Signed-off-by: Michael Werner > --- ... >

Re: [PATCH v14 net-next 08/12] crypto : chtls - CPL handler definition

2018-03-29, 21:27:50 +0530, Atul Gupta wrote: ... > +static void chtls_pass_accept_request(struct sock *sk, > + struct sk_buff *skb) > +{ ... > + if (chtls_get_module(newsk)) > + goto reject; > + inet_csk_reqsk_queue_added(sk); > +

Re: [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Wed, Mar 28, 2018 at 11:41 PM, Joe Perches wrote: > > On Wed, 2018-03-28 at 23:27, Varsha Rao wrote: > > This patch fixes the clang warning of extraneous parentheses, with the > > following coccinelle script. > > > > @@ > > identifier i; > > constant c; > > @@ > > ( > > -((i == c)) > > +i == c

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

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  >application data(4Kb) > compressed/decompressed by ZRAM. For comparison we have used lzbench 

Re: [PATCH] crypto: chelsio: move chcr_ahash_continue declation out of header

Hi, Fix for that is already submitted in below patch. https://patchwork.kernel.org/patch/10292333/ Thanks On 28-03-2018 19:35, Arnd Bergmann wrote: > static function declarations don't belong in a header file, as shown > by this compiler warning: > > In file included from

Re: [PATCH] sunrpc: remove incorrect HMAC request initialization

Applying, thanks!--b. On Wed, Mar 28, 2018 at 10:57:22AM -0700, Eric Biggers wrote: > make_checksum_hmac_md5() is allocating an HMAC transform and doing > crypto API calls in the following order: > > crypto_ahash_init() > crypto_ahash_setkey() > crypto_ahash_digest() > > This is

Re: [PATCH] crypto: cavium: zip: Remove unnecessary parentheses

On Wed, 2018-03-28 at 23:27 +0530, Varsha Rao wrote: > This patch fixes the clang warning of extraneous parentheses, with the > following coccinelle script. > > @@ > identifier i; > constant c; > @@ > ( > -((i == c)) > +i == c > > > > -((i <= c)) > +i <= c Why just the "==" and "<=" cases? Why

Re: [RFC PATCH] crypto: brcm - explicitly cast cipher to hash type

On Wed, Mar 28, 2018 at 05:41:30PM +0200, Stefan Agner wrote: > > Herbert, given that Raveendra agrees to the change, do you want me to > send a non-RFC version or can you merge the patch as is? There is no need to resend it. Thanks, -- Email: Herbert Xu Home Page:

Re: [RFC PATCH] crypto: brcm - explicitly cast cipher to hash type

On 28.03.2018 08:38, Raveendra Padasalagi wrote: > Hi Stefan, > > The change looks to be fine. From the IP point of view its using the > same values in case of AES cipher and hash types so explicit casting > should be ok. Can I take that as an Ack? Herbert, given that Raveendra agrees to the

Re: [RFC PATCH] crypto: brcm - explicitly cast cipher to hash type

Hi Stefan, The change looks to be fine. From the IP point of view its using the same values in case of AES cipher and hash types so explicit casting should be ok. -Raveendra On Sat, Mar 24, 2018 at 4:32 PM, Stefan Agner wrote: > In the AES cases enum spu_cipher_type and enum

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

On 3/27/2018 11:53 PM, Stefano Brivio wrote: > On Tue, 27 Mar 2018 23:06:30 +0530 > Atul Gupta wrote: > >> +static struct tls_context *create_ctx(struct sock *sk) >> +{ >> +struct inet_connection_sock *icsk = inet_csk(sk); >> +struct tls_context *ctx; >> + >> +

Re: [PATCH v13 net-next 08/12] crypto : chtls - CPL handler definition

On 3/27/2018 11:12 PM, Stefano Brivio wrote: > On Tue, 27 Mar 2018 23:06:37 +0530 > Atul Gupta wrote: > >> Exchange messages with hardware to program the TLS session >> CPL handlers for messages received from chip. >> >> Signed-off-by: Atul Gupta

Re: [SPAMMY (6.9)]Re: [PATCH v13 net-next 02/12] ethtool: enable Inline TLS in HW

On 3/28/2018 2:14 AM, Sabrina Dubroca wrote: > 2018-03-27, 23:06:31 +0530, Atul Gupta wrote: >> Ethtool option enables TLS record offload on HW, user >> configures the feature for netdev capable of Inline TLS. >> This allows user to define custom sk_prot for Inline TLS sock >> >> Signed-off-by:

Re: [PATCH v13 net-next 02/12] ethtool: enable Inline TLS in HW

2018-03-27, 23:06:31 +0530, Atul Gupta wrote: > Ethtool option enables TLS record offload on HW, user > configures the feature for netdev capable of Inline TLS. > This allows user to define custom sk_prot for Inline TLS sock > > Signed-off-by: Atul Gupta > Reviewed-by:

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

On Tue, 27 Mar 2018 23:06:30 +0530 Atul Gupta wrote: > +static struct tls_context *create_ctx(struct sock *sk) > +{ > + struct inet_connection_sock *icsk = inet_csk(sk); > + struct tls_context *ctx; > + > + /* allocate tls context */ > + ctx =

Re: [PATCH v13 net-next 07/12] crypto: chtls - Program the TLS session Key

On Tue, 27 Mar 2018 23:06:36 +0530 Atul Gupta wrote: > +static void __set_tcb_field(struct sock *sk, struct sk_buff *skb, u16 word, > + u64 mask, u64 val, u8 cookie, int no_reply) > +{ > + struct chtls_sock *csk =

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

On Tue, 27 Mar 2018 23:06:38 +0530 Atul Gupta wrote: > +static u8 tcp_state_to_flowc_state(u8 state) > +{ > + u8 ret = FW_FLOWC_MNEM_TCPSTATE_ESTABLISHED; > + > + switch (state) { > + case TCP_ESTABLISHED: > + ret =

Re: [PATCH v13 net-next 08/12] crypto : chtls - CPL handler definition

On Tue, 27 Mar 2018 23:06:37 +0530 Atul Gupta wrote: > Exchange messages with hardware to program the TLS session > CPL handlers for messages received from chip. > > Signed-off-by: Atul Gupta > Signed-off-by: Michael Werner >

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

On Tue, 27 Mar 2018 23:06:38 +0530 Atul Gupta wrote: > TLS handler for record transmit. > Create Inline TLS work request and post to FW. > Create Inline TLS record CPLs for hardware > > Signed-off-by: Atul Gupta > Signed-off-by: Michael Werner

Re: [PATCH v13 net-next 07/12] crypto: chtls - Program the TLS session Key

On Tue, 27 Mar 2018 23:06:36 +0530 Atul Gupta wrote: > Initialize the space reserved for storing the TLS keys, > get and free the location where key is stored for the TLS > connection. > Program the Tx and Rx key as received from user in > struct

RE: [PATCH] omap-aes - fix crypto cleanup

Hi Tero, > Also, I think this patch should be split up in two, as there are two > issues you are fixing; the bad pointer issue (which I think you only > fixed partially, also the in->sgl has similar problem), and the missing > output IVI. Why is this needed btw, I have never faced the requirement

RE: [PATCH] omap-crypto - fix kernel oops and output buffer update

Hi Tero, > I have a couple of additional comments, but can't add them as the patch > content is an attachment (like, I would not add the WARN_ON.) Overall, > the issue you have found is a legitimate problem, and should be fixed. I have used WARN_ON() to have some very visible output, I agree it

Re: [RESEND] SHASH_DESC_ON_STACK macro

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 > include/crypto/hash.h:154: > > #define SHASH_DESC_ON_STACK(shash, ctx)

RE: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Yael Chemla <yael.che...@foss.arm.com>; Mike Snitzer <snit...@redhat.com> Cc: Alasdair Kergon <a...@redhat.com>; dm-de...@redhat.com; linux-ker...@vger.kernel.org; ofir.dr...@gmail.com; Yael Chemla <yael.che...@arm.com>; linux-crypto@vger.kernel.org; gi...@benyossef.com Su

RE: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

;yael.che...@foss.arm.com> Cc: Alasdair Kergon <a...@redhat.com>; Mike Snitzer <snit...@redhat.com>; dm-de...@redhat.com; linux-ker...@vger.kernel.org; ofir.dr...@gmail.com; Yael Chemla <yael.che...@arm.com>; linux-crypto@vger.kernel.org; gi...@benyossef.com Subject: Re: [dm-devel] [P

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Mike and others, did anyone even try to run veritysetup tests? We have verity-compat-test in our testsuite, is has even basic FEC tests included. We just added userspace verification of FEC RS codes to compare if kernel behaves the same. I tried to apply three last dm-verity patches from

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

[+Cc linux-crypto] Hi Yael, On Sun, Mar 25, 2018 at 07:41:30PM +0100, Yael Chemla wrote: > Allow parallel processing of bio blocks by moving to async. completion > handling. This allows for better resource utilization of both HW and > software based hash tfm and therefore better performance

Re: [PATCH 07/10] kbuild: clean up *-asn1.[ch] patterns from top-level Makefile

+CC linux-crypto@vger.kernel.org No functional change, though. 2018-03-23 22:04 GMT+09:00 Masahiro Yamada : > Clean up these patterns from the top Makefile to omit 'clean-files' > in each Makefile. > > Signed-off-by: Masahiro Yamada

Re: [PATCH 08/10] kbuild: rename *-asn1.[ch] to *.asn.[ch]

+CC linux-crypto@vger.kernel.org No functional change, though. (I fixed up the subject.) 2018-03-23 22:04 GMT+09:00 Masahiro Yamada : > Our convention is to distinguish file types by suffixes with a period > as a separator. > > *-asn1.[ch] is a different pattern

Re: [PATCH 06/10] .gitignore: move *-asn1.[ch] patterns to the top-level .gitignore

+CC linux-crypto@vger.kernel.org No functional change, though. 2018-03-23 22:04 GMT+09:00 Masahiro Yamada : > These are common patterns where source files are parsed by the > asn1_compiler. > > Signed-off-by: Masahiro Yamada > --- >

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

On Fri, Mar 16, 2018 at 8:56 AM, Herbert Xu wrote: > 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

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

On 26/03/18 01:50 PM, Arnd Bergmann wrote: > I wouldn't expect it to matter: the byte swap is almost always much > cheaper compared to the actual bus access for the MMIO, and I > would also guess that modern compilers can eliminate the double > byte swap on architectures where writel() is an

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

On Mon, Mar 26, 2018 at 6:21 PM, Logan Gunthorpe wrote: > > > On 26/03/18 04:53 AM, Arnd Bergmann wrote: >> On most architectures, this is not important: >> - For x86, the stores are aways atomic and no additional barriers >> are needed, so the two are the same >> - For ARM

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

On 26/03/18 04:53 AM, Arnd Bergmann wrote: > On most architectures, this is not important: > - For x86, the stores are aways atomic and no additional barriers > are needed, so the two are the same > - For ARM (both 32 and 64-bit), powerpc and many others, we don't > use the generic iowrite()

Re: in-kernel user of ecdsa

On 03/12/2018 07:07 PM, Tudor Ambarus wrote: Would you consider using ECDSA in the kernel module signing facility? Any feedback is good. I can invest some time to make this happen, if needed. When compared with RSA, ECDSA has shorter keys, the key generation process is faster, the sign

Re: [PATCH v6 04/12] ima: Introduce is_ima_sig()

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > With the introduction of another IMA signature type (modsig), some places > will need to check for both of them. It is cleaner to do that if there's a > helper function to tell whether an xattr_value represents an IMA > signature.

Re: [PATCH v6 11/12] ima: Implement support for module-style appended signatures

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > This patch actually implements the appraise_type=imasig|modsig option, > allowing IMA to read and verify modsig signatures. > > In case both are present in the same file, IMA will first check whether the > key used by the xattr

Re: [PATCH v6 12/12] ima: Write modsig to the measurement list

On Fri, 2018-03-16 at 17:38 -0300, Thiago Jung Bauermann wrote: > Define new "d-sig" template field which holds the digest that is expected > to match the one contained in the modsig. > > Also add modsig support to the "sig" template field, allowing the the > contents of the modsig to be included

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

On Wed, Mar 21, 2018 at 5:37 PM, 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(),

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

On 3/23/2018 12:42 PM, Tudor Ambarus wrote: > In caam's aead_setkey we save pointers to the authenc keys in a > local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > > Signed-off-by: Tudor Ambarus

Re: [PATCH v2 4/9] crypto: caam/qi - don't leak pointers to authenc keys

On 3/23/2018 12:42 PM, Tudor Ambarus wrote: > In caam/qi's aead_setkey we save pointers to the authenc keys in > a local variable of type struct crypto_authenc_keys and we don't > zeroize it after use. Fix this and don't leak pointers to the > authenc keys. > > Signed-off-by: Tudor Ambarus

Re: [PATCH v6 0/5] add compression algorithm zBeWalgo

Hi Benjamin, Thanks for the nice present and good testing! I hope to grab a chance to test this shiny new algorithm but is busy this week. Hopefully, I will get that soon and feedback to you asap. Thanks. On Mon, Mar 26, 2018 at 10:31:40AM +0200, Benjamin Warnke wrote: > This patch series adds

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

2018-03-23 16:36 GMT+01:00 Herbert Xu : > On Thu, Mar 15, 2018 at 12:18:58PM +0100, Salvatore Mesoraca wrote: >> >> +#define MAX_BLOCKSIZE 16 >> + >> +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS >> +#define MAX_ALIGNMASK 15 >> +#else >> +#define MAX_ALIGNMASK 0 >>

Re: [PATCH 0/3] crypto: inside-secure: improve clock management

Hi Herbert, On sam., mars 24 2018, Herbert Xu wrote: > On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote: >> Hi, >> >> This short series fixes the way the clocks are used for the SafeXcel >> EIP-197 controller embedded in the Marvell Armada 7K/8K

Re: [PATCH v2 net-next 0/6] TLS Rx

From: Dave Watson Date: Thu, 22 Mar 2018 10:09:44 -0700 > TLS tcp socket RX implementation, to match existing TX code. Looks great Dave. Applied, and once my build tests finish I'll push this out to net-next. In some of the new functions, reverse christmas tree ordering of

Re: [PATCH] crypto: cavium: cpt: Replace mdelay with msleep in cpt_device_init

On Sun, Mar 18, 2018 at 10:50:38PM +0800, Jia-Ju Bai wrote: > cpt_device_init() is never called in atomic context. > > The call chain ending up at cpt_device_init() is: > [1] cpt_device_init() <- cpt_probe() > cpt_probe() is only set as ".probe" in pci_driver structure > "cpt_pci_driver". > >

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

Leonard Crestez wrote: > 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 checkout), defeating

Re: [PATCH] crypto: doc - Document remaining members in struct crypto_alg

On Wed, Mar 14, 2018 at 05:15:52PM -0500, Gary R Hook wrote: > Add missing comments for union members ablkcipher, blkcipher, > cipher, and compress. This silences complaints when building > the htmldocs. > > Fixes: 0d7f488f0305a (crypto: doc - cipher data structures) > Signed-off-by: Gary R Hook

Re: [PATCH 19/47] crypto: remove blackfin CRC driver

On Wed, Mar 14, 2018 at 04:35:32PM +0100, Arnd Bergmann wrote: > The blackfin architecture is getting removed, so this > driver won't be used any more. > > Signed-off-by: Arnd Bergmann Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH v2 0/2] Keystone2 HW random generator

On Tue, Mar 13, 2018 at 01:33:29PM -0400, Vitaly Andrianov wrote: > Keyston2 Security Accelerator has a hardware random generator sub-module. > This series adds the driver for the sub-module. > > Changes in v2: > - Changed subject prefix in 1/2 patch > - renamed dts node > > Vitaly Andrianov

Re: [PATCH 0/3] crypto: inside-secure: improve clock management

On Tue, Mar 13, 2018 at 05:48:39PM +0100, Gregory CLEMENT wrote: > Hi, > > This short series fixes the way the clocks are used for the SafeXcel > EIP-197 controller embedded in the Marvell Armada 7K/8K SoCs. On these > SoCs a second one is needed in order to clock the registers. It was > not

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

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 Yongjun

Re: [PATCH 2/2] crypto: talitos: Delete an error message for a failed memory allocation in talitos_edesc_alloc()

On Mon, Mar 12, 2018 at 02:32:58PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 12 Mar 2018 14:18:23 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle

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

On Thu, Mar 15, 2018 at 12:18:58PM +0100, Salvatore Mesoraca wrote: > > +#define MAX_BLOCKSIZE 16 > + > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS > +#define MAX_ALIGNMASK 15 > +#else > +#define MAX_ALIGNMASK 0 > +#endif > + Hmm, this won't work. Just because you have efficient unaligned

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

On 07.03.2018 18:56, Maciej S. Szmigiero wrote: > On 07.03.2018 16:44, David Howells wrote: >> Maciej S. Szmigiero wrote: >> >>> + if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) { >> >> I'm going to change this to '== 0' rather than '!'. > > No problem. I cannot

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

Hi Nick / Sergey, We have compared LZ4 Dyn with Original LZ4 using some samples of realtime application data(4Kb) compressed/decompressed by ZRAM. For comparison we have used lzbench (https://github.com/inikep/lzbench) we have implemented dedicated LZ4 Dyn API & kept last literal length as 6

Re: [PATCH] omap-aes - fix crypto cleanup and IV reporting

Hi Francis, This has similar checkpatch issues + being split into multipart message as your other patch. Also, I think this patch should be split up in two, as there are two issues you are fixing; the bad pointer issue (which I think you only fixed partially, also the in->sgl has similar

Re: [PATCH] omap-crypto - fix kernel oops and output buffer update

On 23/03/18 15:50, Tero Kristo wrote: Hi Francis, Your email program is still messing up things, the patch was sent as a multipart message. Use git-send-email tool or something similar if possible. Also, there are at least two checkpatch issues (run scripts/checkpatch.pl -strict ), in

Re: [PATCH] omap-crypto - fix kernel oops and output buffer update

Hi Francis, Your email program is still messing up things, the patch was sent as a multipart message. Use git-send-email tool or something similar if possible. Also, there are at least two checkpatch issues (run scripts/checkpatch.pl -strict ), in addition to the UTF-8 formatted message

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

Hi Nick, Thanks for your comments, Please check my reply to few of your comments. I will be sharing benchmarking figures separately. > >> +if (curr_offset > 127) { >> +curr_offset = (curr_offset << 1) | DYN_BIT; >> +

Re: [PATCH 2/5 v4] crypto: add zBeWalgo to crypto-api

Hi Benjamin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING 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] crypto: talitos - fix IPsec cipher in length

On 3/22/2018 12:04 PM, Christophe LEROY wrote: > 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

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 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:

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