Re: [tpmdd-devel] in-kernel user of ecdsa

Am Montag, 12. März 2018, 22:55:35 CET schrieb James Bottomley: Hi James, > > ECDSA is not implemented currently in the kernel crypto API. > > an ECDSA signature is produced as a ECDH operation using the DSA > algorithm instead of KDFe, so it's trivial with what we have; signature >

Re: [tpmdd-devel] in-kernel user of ecdsa

On Mon, 2018-03-12 at 20:56 +0100, Stephan Mueller wrote: > Am Montag, 12. März 2018, 19:09:18 CET schrieb James Bottomley: > > Hi James, > > > > > On Mon, 2018-03-12 at 19:07 +0200, Tudor Ambarus wrote: > > > > > > Hi, > > > > > > Would you consider using ECDSA in the kernel module signing >

Re: [tpmdd-devel] in-kernel user of ecdsa

Am Montag, 12. März 2018, 19:09:18 CET schrieb James Bottomley: Hi James, > On Mon, 2018-03-12 at 19:07 +0200, Tudor Ambarus wrote: > > Hi, > > > > Would you consider using ECDSA in the kernel module signing facility? > > When compared with RSA, ECDSA has shorter keys, the key generation > >

Re: [tpmdd-devel] in-kernel user of ecdsa

On Mon, 2018-03-12 at 19:07 +0200, Tudor Ambarus wrote: > Hi, > > Would you consider using ECDSA in the kernel module signing facility? > When compared with RSA, ECDSA has shorter keys, the key generation > process is faster, the sign operation is faster, but the verify > operation is slower than

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

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 defined in this patch,

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

+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 defined in this patch, shouldn't it check if buf is valid before passing into the internal functions

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

On Mon, 2018-03-12 at 12:58 +0200, Jarkko Sakkinen wrote: > On Sat, 2018-03-10 at 14:13 -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

Re: what is a replacement for private_AES_set_encrypt_key and AES_encrypt functions

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 - replace bit-sliced OpenSSL NEON

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

Le 12/03/2018 à 14:32, SF Markus Elfring a écrit : 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 software. Signed-off-by:

Re: [PATCH 1/2] crypto: talitos: Use common error handling code in talitos_edesc_alloc()

Le 12/03/2018 à 14:31, SF Markus Elfring a écrit : From: Markus Elfring Date: Mon, 12 Mar 2018 14:08:55 +0100 Add jump targets so that an error message and the setting of a specific error code is stored only once at the end of this function. Signed-off-by:

Re: [PATCH v10 crypto 07/11] chtls: Program the TLS Key

FULL, keyid); > +} > + > +static void chtls_set_tcb_seqno(struct sock *sk) > +{ > + return chtls_set_tcb_field(sk, 28, ~0ULL, 0); > +} > + > +static void chtls_set_tcb_quiesce(struct sock *sk, int val) > +{ > + return chtls_set_tcb_field(sk, 1, (1ULL << TF_RX_QUIESCE_S), > +TF_RX_QUIESCE_V(val)); > +} Why would you return from a void function? IMHO, it would be more productive if you could address the comments you are receiving a bit more carefully instead of patching them up quickly and race to re-post, because this doesn't seem to gain any time. -- Stefano

Re: [PATCH v10 crypto 09/11] chtls: Inline TLS request Tx/Rx

On Sat, 10 Mar 2018 00:40:14 +0530 Atul Gupta wrote: > TLS handler for record transmit and receive. > Create Inline TLS work request and post to FW. > Create Inline TLS record CPLs for hardware > > Signed-off-by: Atul Gupta > --- >

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

On Sat, 2018-03-10 at 10:29 -0800, James Bottomley wrote: > OK, you might want to wait for v3 then. I've got it working with > sealed (trusted) keys, well except for a problem with the trusted keys > API that means we can't protect the password for policy based keys. I > think the API is finally

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

On Sat, 2018-03-10 at 14:13 -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 sessions for HMAC > capabilities to ensure

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hi Benjamin, On Wed, Mar 07, 2018 at 12:50:08PM +0100, Benjamin Warnke wrote: > Hi Eric, > > > On 06.03.2018 at 23:13, Eric Biggers wrote: > > > > Hi Benjamin, > > > > On Tue, Mar 06, 2018 at 09:23:08PM +0100, Benjamin Warnke wrote: > >> Currently ZRAM uses compression-algorithms from the

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

On 11 March 2018 at 05:16, Vakul Garg wrote: > Hi > > How does this patchset affect the throughput performance of crypto? > Is it expected to increase? > This is about latency not throughput. The throughput may decrease slightly (<1%), but spikes in scheduling latency due to

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

Hi How does this patchset affect the throughput performance of crypto? Is it expected to increase? Regards Vakul > -Original Message- > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- > ow...@vger.kernel.org] On Behalf Of Ard Biesheuvel > Sent: Saturday, March 10, 2018

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

On Sat, 2018-03-10 at 14:49 +0200, Jarkko Sakkinen wrote: > On Wed, 2018-03-07 at 15:29 -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

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

On Wed, 2018-03-07 at 15:29 -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 sessions for HMAC > capabilities to ensure

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

On 07.03.2018 18:31, 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: [RFC PATCH cryptodev] crypto: des3_ede_skciphers[] can be static

On Sat, Mar 03, 2018 at 04:29:46AM +0800, kbuild test robot wrote: > > Fixes: 09c0f03bf8ce ("crypto: x86/des3_ede - convert to skcipher interface") > Signed-off-by: Fengguang Wu Patch applied. Thanks. -- Email: Herbert Xu Home Page:

Re: [PATCH] crypto/ccp - Fill the result buffer only on digest, finup, and final ops

On Wed, Mar 07, 2018 at 11:37:42AM -0600, Gary R Hook wrote: > Any change to the result buffer should only happen on final, finup > and digest operations. Changes to the buffer for update, import, export, > etc, are not allowed. > > Fixes: 66d7b9f6175e ("crypto: testmgr - test misuse of result in

Re: [PATCH] Crypto:Chelsio: no csum offload for ipsec path

On Wed, Feb 28, 2018 at 11:18:08PM +0530, Atul Gupta wrote: > The Inline IPSec driver does not offload csum. > > Signed-off-by: Atul Gupta Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH 0/2] add crypto support for TPM communication

James Bottomley wrote: > To support cryptographic communication with the TPM, we need to add > Cipher FeedBack (CFB) mode for stream encryption because this is the > mandated encryption scheme for all encrypted parameters and responses. >  Additionally, we

Re: [PATCH 1/4] crypto: omap-sham: Remove useless check for non-null request

On Thu, Mar 01, 2018 at 09:50:10PM +0100, Krzysztof Kozlowski wrote: > ahash_request 'req' argument passed by the caller > omap_sham_handle_queue() cannot be NULL here because it is obtained from > non-NULL pointer via container_of(). > > This fixes smatch warning: >

Re: [PATCH 0/2] hwrng: omap: Fix clock resource for Armada 7K/8K

On Wed, Feb 28, 2018 at 03:27:21PM +0100, Gregory CLEMENT wrote: > Hi, > > This short series fixes the way the clocks are used for the SafeXcel > IP-76 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 2/2] crypto: talitos - do not perform unnecessary dma synchronisation

On Mon, Feb 26, 2018 at 05:40:06PM +0100, Christophe Leroy wrote: > req_ctx->hw_context is mainly used only by the HW. So it is not needed > to sync the HW and the CPU each time hw_context in DMA mapped. > This patch modifies the DMA mapping in order to limit synchronisation > to necessary

Re: [PATCH 0/6] crypto: omap: fixes + tweaks for omap crypto

On Tue, Feb 27, 2018 at 03:30:33PM +0200, Tero Kristo wrote: > Hi, > > This series contains a couple of fixes for LPAE data handling (patch #1/#2), > and also a few configuration patches (#3..#6.) Without the fixes, > the driver will see crashes in certain data configs, most notably when > using

Re: [PATCH 1/2] crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf

On Mon, Feb 26, 2018 at 05:40:04PM +0100, Christophe Leroy wrote: > Commit 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping > outside the requests") introduced a persistent dma mapping of > req_ctx->hw_context > Commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash >

Re: [PATCH] hwrng: cavium: make two functions static

On Mon, Feb 26, 2018 at 02:51:19PM +, Colin King wrote: > From: Colin Ian King > > Functions cavium_rng_remove and cavium_rng_remove_vf are local to the > source and do not need to be in global scope, so make them static. > > Cleans up sparse warnings: >

Re: [PATCH 0/3] crypto: inside-secure - fixes for heavy load usage

On Mon, Feb 26, 2018 at 02:45:09PM +0100, Antoine Tenart wrote: > Hi Herbert, > > This series contains 3 patches aimed at fixing issues when the SafeXcel > driver is used under heavy load. The first two patches move DMA mapping > informations to per-request specific contexts and the last one

Re: [PATCH 3/4] crypto: bcm: Constify *hash_alg_name[]

On Fri, Mar 09, 2018 at 06:35:35AM -0800, Joe Perches wrote: > > and likely, as this is a global name, it should > be something like crypto_hash_alg_name crypto_ is not a good prefix here. Perhaps crypto_bcm_. Thanks, -- Email: Herbert Xu Home Page:

Re: [PATCH 3/4] crypto: bcm: Constify *hash_alg_name[]

On 27.02.2018 23:01, Hernán Gonzalez wrote: > Note: This is compile only tested. > No gain from this except some self-documenting. > > Signed-off-by: Hernán Gonzalez > --- > drivers/crypto/bcm/spu.c | 5 +++-- > drivers/crypto/bcm/spu.h | 2 +- > 2 files changed,

Re: [PATCH 3/4] crypto: bcm: Constify *hash_alg_name[]

On Fri, 2018-03-09 at 22:29 +0800, Herbert Xu wrote: > On Tue, Feb 27, 2018 at 07:01:27PM -0300, Hernán Gonzalez wrote: > > Note: This is compile only tested. > > No gain from this except some self-documenting. [] > > diff --git a/drivers/crypto/bcm/spu.c b/drivers/crypto/bcm/spu.c [] > > @@ -23,8

Re: [PATCH 3/4] crypto: bcm: Constify *hash_alg_name[]

On Tue, Feb 27, 2018 at 07:01:27PM -0300, Hernán Gonzalez wrote: > Note: This is compile only tested. > No gain from this except some self-documenting. > > Signed-off-by: Hernán Gonzalez > --- > drivers/crypto/bcm/spu.c | 5 +++-- > drivers/crypto/bcm/spu.h | 2 +- >

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

On 03/08/2018 11:57 PM, 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/ecc: Remove stack VLA usage

On 03/08/2018 11:55 PM, Kees Cook wrote: Looks like there are few intermediate buffers in ecc that should be zeroized as well. Can you send a patch for those? Yeah, I'll take a look. Best, ta

Re: [PATCH RFC 4/5] tls: RX path for ktls

On 03/08/18 09:48 PM, Boris Pismenny wrote: > Hi Dave, > > On 03/08/18 18:50, 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

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

On Thu, Mar 8, 2018 at 1:43 AM, Tudor Ambarus wrote: > Hi, Kees, > > > On 03/07/2018 11:56 PM, 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 RFC 4/5] tls: RX path for ktls

Hi Dave, On 03/08/18 18:50, 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

Re: [PATCH v9 crypto 08/12] chtls: Key program

On 3/7/2018 8:35 PM, Sabrina Dubroca wrote: > 2018-03-06, 21:09:27 +0530, Atul Gupta wrote: > [snip] >> +static int chtls_set_tcb_field(struct sock *sk, u16 word, u64 mask, u64 val) >> +{ >> +struct chtls_sock *csk = rcu_dereference_sk_user_data(sk); >> +struct sk_buff *skb; >> +

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

Hi, Kees, On 03/07/2018 11:56 PM, 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). [1]

Re: [PATCH v9 crypto 06/12] cxgb4: LLD driver changes to enable TLS

On 3/7/2018 6:29 PM, Sabrina Dubroca wrote: > 2018-03-06, 21:09:25 +0530, Atul Gupta wrote: >> Read FW capability. Read key area size. Dump the TLS record count. > That's not a really helpful commit message. Have a look at other > commit messages and try to be more descriptive. > It's also not

Re: [PATCH v3 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

On Wed, Mar 7, 2018 at 8:54 AM, PrasannaKumar Muralidharan wrote: > Hi Rob, > > On 6 March 2018 at 19:25, Rob Herring wrote: >> On Tue, Mar 6, 2018 at 3:32 AM, James Hogan wrote: >>> On Mon, Sep 18, 2017 at 07:32:40PM +0530,

Re: [PATCH v3 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

Hi PrasannaKumar, Le 2018-03-07 15:51, PrasannaKumar Muralidharan a écrit : Hi Paul, On 7 March 2018 at 04:31, Paul Cercueil wrote: Le 2018-03-06 10:32, James Hogan a écrit : On Mon, Sep 18, 2017 at 07:32:40PM +0530, PrasannaKumar Muralidharan wrote: Add RNG node to

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

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. > David > Thanks, Maciej

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

On Tue, 6 Mar 2018 00:21:00 +0200 Vladimir Zapolskiy wrote: > The driver works well on i.MX31 powered boards with device description > taken from board device tree, the only change to add to the driver is > the missing OF device id, the affected list of included headers and >

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

Maciej S. Szmigiero wrote: > + if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) { I'm going to change this to '== 0' rather than '!'. David

Re: [PATCH v9 crypto 08/12] chtls: Key program

2018-03-06, 21:09:27 +0530, Atul Gupta wrote: [snip] > +static int chtls_set_tcb_field(struct sock *sk, u16 word, u64 mask, u64 val) > +{ > + struct chtls_sock *csk = rcu_dereference_sk_user_data(sk); > + struct sk_buff *skb; > + struct cpl_set_tcb_field *req; > + struct

Re: [PATCH v3 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

Hi Rob, On 6 March 2018 at 19:25, Rob Herring wrote: > On Tue, Mar 6, 2018 at 3:32 AM, James Hogan wrote: >> On Mon, Sep 18, 2017 at 07:32:40PM +0530, PrasannaKumar Muralidharan wrote: >>> Add RNG node to jz4780 dtsi. This driver uses registers that are

Re: [PATCH v3 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

Hi Paul, On 7 March 2018 at 04:31, Paul Cercueil wrote: > Le 2018-03-06 10:32, James Hogan a écrit : >> >> On Mon, Sep 18, 2017 at 07:32:40PM +0530, PrasannaKumar Muralidharan >> wrote: >>> >>> Add RNG node to jz4780 dtsi. This driver uses registers that are part of >>> the

Re: [PATCH v3 0/4] crypto: AF_ALG AIO improvements

On Tue, Feb 27, 2018 at 03:08:58PM +0100, Stephan Müller wrote: > Am Freitag, 23. Februar 2018, 13:00:26 CET schrieb Herbert Xu: > > Hi Herbert, > > > On Fri, Feb 23, 2018 at 09:33:33AM +0100, Stephan Müller wrote: > > > A simple copy operation, however, will imply that in one AIO recvmsg > > >

Re: [PATCH v9 crypto 06/12] cxgb4: LLD driver changes to enable TLS

2018-03-06, 21:09:25 +0530, Atul Gupta wrote: > Read FW capability. Read key area size. Dump the TLS record count. That's not a really helpful commit message. Have a look at other commit messages and try to be more descriptive. It's also not clear if those changes belong together in one patch,

Re: [PATCH v9 crypto 02/12] ethtool: enable Inline TLS in HW

On 3/7/2018 6:05 PM, Sabrina Dubroca wrote: > Since you're saying the driver supports offloading TLS records to the > HW, why not call the feature "record offloading"? With, for example, > NETIF_F_HW_TLS_RECORD as the feature, and maybe "tls-hw-record" for > the ethtool string. This "Inline

Re: [PATCH v9 crypto 02/12] ethtool: enable Inline TLS in HW

Since you're saying the driver supports offloading TLS records to the HW, why not call the feature "record offloading"? With, for example, NETIF_F_HW_TLS_RECORD as the feature, and maybe "tls-hw-record" for the ethtool string. This "Inline TLS" name sounds rather like marketing to me.

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hi Eric, On 06.03.2018 at 23:13, Eric Biggers wrote: > > Hi Benjamin, > > On Tue, Mar 06, 2018 at 09:23:08PM +0100, Benjamin Warnke wrote: >> Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM >> compresses each page individually. As a result the compression algorithm is >>

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

On 3/7/2018 3:53 PM, Sabrina Dubroca wrote: > 2018-03-06, 21:05:23 +0530, Atul Gupta wrote: >> Series for Chelsio Inline TLS driver (chtls) >> >> Use tls ULP infrastructure to register chtls as Inline TLS driver. >> Chtls use TCP Sockets to transmit and receive TLS record. TCP proto_ops is >>

Re: [PATCH v9 crypto 01/12] tls: tls_device struct to register TLS drivers

On 3/7/2018 3:46 PM, Sabrina Dubroca wrote: > Hello Atul, > > One quick note before you start replying: please fix your email > client, as you've been told before. Quoting has to add a quoting > marker (the '>' character) at the beginning of the line, otherwise > it's impossible to separate your

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hello, On(07/03/2018 03:12),Sergey Senozhatsky wrote: > > Hello, > > On (03/06/18 20:59), Benjamin Warnke wrote: >> Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM >> compresses each page individually. As a result the compression algorithm >> is >> forced to use a

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

pushes it back to upper layers. No data processing happens at this >> @@ -120,11 +122,12 @@ struct ahash_request { >> * you want to save partial result of the transformation after >> * processing certain amount of data and reload this partial resu

Re: [PATCH v9 crypto 01/12] tls: tls_device struct to register TLS drivers

Hello Atul, One quick note before you start replying: please fix your email client, as you've been told before. Quoting has to add a quoting marker (the '>' character) at the beginning of the line, otherwise it's impossible to separate your reply from the email you're quoting. 2018-03-06,

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

On Tue, Mar 6, 2018 at 11:22 AM, Herbert Xu wrote: > 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. > > Hmm, the first series has

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hello, On (03/06/18 20:59), Benjamin Warnke wrote: >Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM >compresses each page individually. As a result the compression algorithm >is >forced to use a very small sliding window. None of the available >compression

Re: [PATCH v3 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

Le 2018-03-06 10:32, James Hogan a écrit : On Mon, Sep 18, 2017 at 07:32:40PM +0530, PrasannaKumar Muralidharan wrote: Add RNG node to jz4780 dtsi. This driver uses registers that are part of the register set used by Ingenic CGU driver. Use regmap in RNG driver to access its register. Create

Re: [RESEND PATCH v3] crypto: add zBeWalgo compression for zram

Hi Benjamin, On Tue, Mar 06, 2018 at 09:23:08PM +0100, Benjamin Warnke wrote: > Currently ZRAM uses compression-algorithms from the crypto-api. ZRAM > compresses each page individually. As a result the compression algorithm is > forced to use a very small sliding window. None of the available

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

hash from the driver and > * pushes it back to upper layers. No data processing happens at this > @@ -120,11 +122,12 @@ struct ahash_request { > * you want to save partial result of the transformation after > * processing certain amount of data and r

Re: [PATCH v11 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

On 06/03/18 04:57 AM, Andy Shevchenko wrote: On Tue, Mar 6, 2018 at 1:46 PM, Greg Kroah-Hartman wrote: On Tue, Mar 06, 2018 at 12:48:29PM +0200, Andy Shevchenko wrote: On Mon, Mar 5, 2018 at 9:08 PM, Logan Gunthorpe wrote: Clean up the

Re: [PATCH v11 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

On 06/03/18 05:37 AM, Horia Geantă wrote: On 3/5/2018 9:08 PM, Logan Gunthorpe wrote: Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of

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

<ganes...@chelsio.com> Subject: RE: [PATCH v9 crypto 00/12] Chelsio Inline TLS > -Original Message- > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- > ow...@vger.kernel.org] On Behalf Of Atul Gupta > Sent: Tuesday, March 6, 2018 9:05 PM >

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

> -Original Message- > From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto- > ow...@vger.kernel.org] On Behalf Of Atul Gupta > Sent: Tuesday, March 6, 2018 9:05 PM > To: davejwat...@fb.com; da...@davemloft.net; > herb...@gondor.apana.org.au > Cc: linux-crypto@vger.kernel.org;

Re: [PATCH v3 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

On Tue, Mar 6, 2018 at 3:32 AM, James Hogan wrote: > On Mon, Sep 18, 2017 at 07:32:40PM +0530, PrasannaKumar Muralidharan wrote: >> Add RNG node to jz4780 dtsi. This driver uses registers that are part of >> the register set used by Ingenic CGU driver. Use regmap in RNG driver

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

On Tue, Mar 06, 2018 at 12:47:45PM +, Ard Biesheuvel wrote: > On 6 March 2018 at 12:35, Dave Martin wrote: > > 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

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

On 6 March 2018 at 12:35, Dave Martin wrote: > 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

Re: [PATCH v11 6/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

On 3/5/2018 9:08 PM, Logan Gunthorpe wrote: > Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 > functions in non-64bit cases in favour of the new common > io-64-nonatomic-lo-hi header. > > To be consistent with CAAM engine HW spec: in case of 64-bit registers, > irrespective of

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

6.16b > + eor Y_3.16b, Y_3.16b, TWEAKV7.16b > + > + /* > + * De-interleave the 'x' and 'y' elements of each block, i.e. make it so > + * that the X[0-3] registers contain only the second halves of blocks, > + * and the Y[0-3] registers conta

Re: [PATCH v11 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

On Tue, Mar 6, 2018 at 1:46 PM, Greg Kroah-Hartman wrote: > On Tue, Mar 06, 2018 at 12:48:29PM +0200, Andy Shevchenko wrote: >> On Mon, Mar 5, 2018 at 9:08 PM, Logan Gunthorpe wrote: >> > Clean up the ifdefs which conditionally defined the

Re: [PATCH v11 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

On Tue, Mar 06, 2018 at 12:48:29PM +0200, Andy Shevchenko wrote: > On Mon, Mar 5, 2018 at 9:08 PM, Logan Gunthorpe wrote: > > Clean up the ifdefs which conditionally defined the io{read|write}64 > > functions in favour of the new common io-64-nonatomic-lo-hi header. > > >

Re: [PATCH v11 7/7] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

On Mon, Mar 5, 2018 at 9:08 PM, Logan Gunthorpe wrote: > Clean up the ifdefs which conditionally defined the io{read|write}64 > functions in favour of the new common io-64-nonatomic-lo-hi header. > #include > #include > #include > +#include A nit, can we preserve

Re: [PATCH v3 3/4] crypto: jz4780-rng: Add RNG node to jz4780.dtsi

On Mon, Sep 18, 2017 at 07:32:40PM +0530, PrasannaKumar Muralidharan wrote: > Add RNG node to jz4780 dtsi. This driver uses registers that are part of > the register set used by Ingenic CGU driver. Use regmap in RNG driver to > access its register. Create 'simple-bus' node, make CGU and RNG node

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. Hmm, the first series has already been applied. So if you want to change it then you'll need to send patches based on

Re: Why are we testing an intermediate result in ahash?

On Mon, Mar 05, 2018 at 02:30:57PM -0600, Gary R Hook wrote: > > So a failure to communicate a newly-required behavior change, much less > document it, is addressed by breaking drivers? For some reason this seems > wrong. > > It's also wrong to change the documentation after the fact, and after

Re: [PATCH 0/5] crypto: chelsio - Cleanup and bug fixes

Hi Herbert, Please ignore this series. V2 sent with minor change. On 11-01-2018 16:45, Harsh Jain wrote: > This series include cleanup, bug fixes and authenc algo supporting > ctr(aes)-sha operation. > > Harsh Jain (5): > crypto: chelsio - Fix Indentation > crypto: chelsio - check for sg

Re: [PATCH 1/2] Documentation: dt: rng: add bindings doc for Keystone SA HWRNG driver

On Thu, Mar 01, 2018 at 07:54:59AM -0500, Vitaly Andrianov wrote: > The Keystone SA module has a hardware random generator module. > This commit adds binding doc for the KS2 SA HWRNG driver. Preferred subject prefix is "dt-bindings: rng: ..." > > Signed-off-by: Vitaly Andrianov

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

Hi Vladimir, On Mon, Mar 5, 2018 at 8:44 PM, Vladimir Zapolskiy wrote: > Yes, I have a pretty good i.MX31 dtsi change (tested everything but USB > and multimedia, and that notorious watchdog problem still has to be > agreed with Uwe and solved), but I'm trying to save my time a

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

On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote: > The driver works well on i.MX31 powered boards with device description > taken from board device tree, the only change to add to the driver is > the missing OF device id, the affected list of included headers and >

Re: [PATCH v2 1/2] dt-bindings: rng: Document Freescale i.MX21 and i.MX31 RNGA compatibles

On Mon, Mar 5, 2018 at 7:20 PM, Vladimir Zapolskiy wrote: > Freescale i.MX21 and i.MX31 SoCs contain a Random Number Generator > Accelerator module (RNGA), which is replaced by RNGB and RNGC modules > on later i.MX SoC series, the change adds a new compatible property > to

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

Hi Fabio, On 03/06/2018 12:24 AM, Fabio Estevam wrote: > Hi Vladimir, > > On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote: >> The driver works well on i.MX31 powered boards with device description >> taken from board device tree, the only change to add to the driver is

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

Hi Vladimir, On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote: > The driver works well on i.MX31 powered boards with device description > taken from board device tree, the only change to add to the driver is > the missing OF device id, the affected list of included

Re: [PATCH 1/2] dt-bindings: rng: Document Freescale i.MX31 RNGA compatible

On Mon, Feb 26, 2018 at 08:38:48PM +0200, Vladimir Zapolskiy wrote: > Freescale i.MX31 SoC contains a Security Random Number Generator > Accelerator module (RNGA), which is replaced by RNGB and RNGC modules > on later i.MX SoC series, the change adds a new compatible property > to describe the

Re: Why are we testing an intermediate result in ahash?

On 03/05/2018 12:31 PM, Kamil Konieczny wrote: On 05.03.2018 18:47, Gary R Hook wrote: On 03/05/2018 03:57 AM, Kamil Konieczny wrote: On 02.03.2018 22:11, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash operations, the result buffer

Re: Why are we testing an intermediate result in ahash?

On 3/5/2018 12:31 PM, Kamil Konieczny wrote: > > > On 05.03.2018 18:47, Gary R Hook wrote: >> On 03/05/2018 03:57 AM, Kamil Konieczny wrote: >>> >>> >>> On 02.03.2018 22:11, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash

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

On 03/05/2018 07:10 AM, 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 the Coccinelle software.

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

On 3/5/18 7:10 AM, 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 the Coccinelle software.

Re: Why are we testing an intermediate result in ahash?

On 05.03.2018 18:47, Gary R Hook wrote: > On 03/05/2018 03:57 AM, Kamil Konieczny wrote: >> >> >> On 02.03.2018 22:11, Gary R Hook wrote: >>> Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for >>> async hash operations, >>> the result buffer with a known value and to test

Re: Why are we testing an intermediate result in ahash?

On 03/05/2018 03:57 AM, Kamil Konieczny wrote: On 02.03.2018 22:11, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash operations, the result buffer with a known value and to test the buffer against that value at intermediate steps. If the

Re: [PATCH 1/2] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling

On Mon, Mar 05, 2018 at 06:58:32AM -0800, James Bottomley wrote: > On Mon, 2018-03-05 at 13:35 +0200, Jarkko Sakkinen wrote: > > On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote: > > > > > > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h > > > new file mode 100644

Re: Why are we testing an intermediate result in ahash?

On 03/05/2018 03:50 AM, Herbert Xu wrote: On Fri, Mar 02, 2018 at 03:11:52PM -0600, Gary R Hook wrote: Commit 466d7b9f6 (cryptodev-2.6) added code to testmgr to populate, for async hash operations, the result buffer with a known value and to test the buffer against that value at intermediate

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

On Mon, 2018-03-05 at 07:04 -0700, 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

Re: [PATCH 1/2] tpm2-sessions: Add full HMAC and encrypt/decrypt session handling

On Mon, 2018-03-05 at 13:35 +0200, Jarkko Sakkinen wrote: > On Fri, Mar 02, 2018 at 10:06:15PM -0800, James Bottomley wrote: > > > > diff --git a/drivers/char/tpm/tpm2b.h b/drivers/char/tpm/tpm2b.h > > new file mode 100644 > > index ..c7726f2895aa > > --- /dev/null > > +++

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

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 sessions for HMAC > capabilities to

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