[PATCH 2/2] tpm2-sessions: NOT FOR COMMITTING add sessions testing

This runs through a preset sequence using sessions to demonstrate that the session handling code functions. It does both HMAC, encryption and decryption by testing an encrypted sealing operation with authority and proving that the same sealed data comes back again via an HMAC and response

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

This code adds true session based HMAC authentication plus parameter decryption and response encryption using AES. The basic design of this code is to segregate all the nasty crypto, hash and hmac code into tpm2-sessions.c and export a usable API. The API first of all starts off by gaining a

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

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 integrity and to use parameter and response encryption to ensure

Re: [PATCH 2/3] crypto: ccp - return an actual key size from RSA max_size callback

On 03/02/2018 05:58 PM, Maciej S. Szmigiero wrote: On 03.03.2018 00:49, Hook, Gary wrote: On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote: Thanks. However, what about the first patch from this series? Without it, while it no longer should cause a buffer overflow, in-kernel X.509 certificate

Re: [PATCH 2/3] crypto: ccp - return an actual key size from RSA max_size callback

On 03.03.2018 00:49, Hook, Gary wrote: > On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote: >> On 02.03.2018 17:44, Herbert Xu wrote: >>> On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote: rsa-pkcs1pad uses a value returned from a RSA implementation max_size callback as a

Re: [PATCH 2/3] crypto: ccp - return an actual key size from RSA max_size callback

On 3/2/2018 5:15 PM, Maciej S. Szmigiero wrote: On 02.03.2018 17:44, Herbert Xu wrote: On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote: rsa-pkcs1pad uses a value returned from a RSA implementation max_size callback as a size of an input buffer passed to the RSA

Re: [PATCH 2/3] crypto: ccp - return an actual key size from RSA max_size callback

On 02.03.2018 17:44, Herbert Xu wrote: > On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote: >> rsa-pkcs1pad uses a value returned from a RSA implementation max_size >> callback as a size of an input buffer passed to the RSA implementation for >> encrypt and sign operations. >> >>

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 > --- > des3_ede_glue.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Why are we testing an intermediate result in ahash?

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 result buffer changes the operation is failed. My question is: why? What problem does

[cryptodev:master 109/128] arch/x86/crypto/des3_ede_glue.c:407:21: sparse: symbol 'des3_ede_skciphers' was not declared. Should it be static?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master head: 23ea8b63a1e2e15199da4461eb303f642fa04f60 commit: 09c0f03bf8ce9304e0d17131c46690b2c95209f4 [109/128] crypto: x86/des3_ede - convert to skcipher interface reproduce: # apt-get install sparse

[RFC PATCH cryptodev] crypto: des3_ede_skciphers[] can be static

Fixes: 09c0f03bf8ce ("crypto: x86/des3_ede - convert to skcipher interface") Signed-off-by: Fengguang Wu --- des3_ede_glue.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/des3_ede_glue.c b/arch/x86/crypto/des3_ede_glue.c index

[PATCH] fscrypt: add Speck128/256 support

Hello, here's a patch which adds Speck128/256 support to fscrypt, for ext4/f2fs/ubifs encryption. Note that this can be applied independently of the patches that added Speck to the crypto API since there is no hard dependency, but the crypto API support is needed for Speck-encrypted files to

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

On 2/26/2018 6:40 PM, 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 > on SEC1") introduced

Re: [PATCH 17/18] crypto: talitos - chain in buffered data for ahash on SEC1

Le 02/03/2018 à 18:27, Horia Geantă a écrit : On 10/6/2017 4:05 PM, Christophe Leroy wrote: [...] @@ -1778,6 +1814,36 @@ static int common_nonsnoop_hash(struct talitos_edesc *edesc, if (is_sec1 && from_talitos_ptr_len(>ptr[3], true) == 0)

Re: [PATCH 1/2] crypto: ccp: Fix sparse, use plain integer as NULL pointer

Hi Herbert, On 03/02/2018 10:41 AM, Herbert Xu wrote: On Thu, Feb 15, 2018 at 01:34:44PM -0600, Brijesh Singh wrote: Fix sparse warning: Using plain integer as NULL pointer. Replaces assignment of 0 to pointer with NULL assignment. Fixes: 200664d5237f (Add Secure Encrypted Virtualization

Re: [PATCH 2/3] crypto: ccp - return an actual key size from RSA max_size callback

On Sat, Feb 24, 2018 at 05:03:21PM +0100, Maciej S. Szmigiero wrote: > rsa-pkcs1pad uses a value returned from a RSA implementation max_size > callback as a size of an input buffer passed to the RSA implementation for > encrypt and sign operations. > > CCP RSA implementation uses a hardware input

Re: [PATCH] crypto/ccp: don't disable interrupts while setting up debugfs

On Fri, Feb 23, 2018 at 11:33:07PM +0100, Sebastian Andrzej Siewior wrote: > I don't why we need take a single write lock and disable interrupts > while setting up debugfs. This is what what happens when we try anyway: > > |ccp :03:00.2: enabling device ( -> 0002) > |BUG: sleeping

Re: [PATCH v4 0/4] Enable CAAM on i.MX7s fix TrustZone issues

On Thu, Feb 22, 2018 at 02:22:46PM +, Rui Miguel Silva wrote: > For v4 I am taking over this patch series as all the left over patches were > implemented by me. > > V4: > - removed patch: [PATCH v3 2/5] crypto: caam: Fix endless loop when RNG is > already initialized from the series since

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

On Fri, Feb 23, 2018 at 10:01:40AM +0100, Antoine Tenart wrote: > The Atmel AES driver uses memzero_explicit on the keys on error, but the > variable zeroed isn't the right one because of a typo. Fix this by using > the right variable. > > Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support

Re: [PATCH v2] crypto: ccp: add check to get PSP master only when PSP is detected

Brijesh Singh wrote: > Paulian reported the below kernel crash on Ryzen 5 system: > > BUG: unable to handle kernel NULL pointer dereference at 0073 > RIP: 0010:.LC0+0x41f/0xa00 > RSP: 0018:a9968003bdd0 EFLAGS: 00010002 > RAX: b113b130 RBX:

Re: [PATCH 00/30] crypto: x86 glue code cleanup/conversion

On Mon, Feb 19, 2018 at 11:47:58PM -0800, Eric Biggers wrote: > Hi, > > I got tired of seeing some block cipher implementations using the old > API (blkcipher or ablkcipher) and some using the new API (skcipher)... > so this series makes a dent in the problem by converting all the > remaining x86

Re: [PATCH] crypto: marvell/cesa - Clean up redundant #include

On Mon, Feb 19, 2018 at 01:55:36PM +, Robin Murphy wrote: > The inclusion of dma-direct.h was only needed temporarily to prevent > breakage from the DMA API rework, since the actual CESA fix making it > redundant was merged in parallel. Now that both have landed, it can go. > > Signed-off-by:

Re: [PATCH 0/4] cleanups and new HW rev support

On Mon, Feb 19, 2018 at 02:51:20PM +, Gilad Ben-Yossef wrote: > This patch set introduces backward compatible support for the older > CryptoCell hardware revision 710 and 630 along some minor code > cleanups. > > Gilad Ben-Yossef (4): > crypto: ccree: remove unused definitions >

Re: [PATCH 1/2] crypto: ccp: Fix sparse, use plain integer as NULL pointer

On Thu, Feb 15, 2018 at 01:34:44PM -0600, Brijesh Singh wrote: > Fix sparse warning: Using plain integer as NULL pointer. Replaces > assignment of 0 to pointer with NULL assignment. > > Fixes: 200664d5237f (Add Secure Encrypted Virtualization ...) > Cc: Borislav Petkov > Cc:

Re: [PATCH Resend 0/5] hwrng: stm32 - Improvement for stm32-rng

On Thu, Feb 15, 2018 at 02:03:07PM +0100, Lionel Debieve wrote: > This set of patches add extended functionalities for stm32 rng > driver. > Patch #1 includes a reset during probe to avoid any error status > which can occur during bootup process and keep safe rng integrity. > > Patch #3 adds a

Re: [PATCH Resend 0/5] hwrng: stm32 - Improvement for stm32-rng

On Thu, Feb 22, 2018 at 04:25:46PM +0100, Alexandre Torgue wrote: > Hi > > On 02/22/2018 03:03 PM, Herbert Xu wrote: > >On Thu, Feb 15, 2018 at 02:03:07PM +0100, Lionel Debieve wrote: > >>This set of patches add extended functionalities for stm32 rng > >>driver. > >>Patch #1 includes a reset

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

On Tue, 27 Feb 2018 15:08:58 +0100 Stephan Müller wrote: > Am Freitag, 23. Februar 2018, 13:00:26 CET schrieb Herbert Xu: > > Hi Herbert, Hi Stephan / Herbert, > > > On Fri, Feb 23, 2018 at 09:33:33AM +0100, Stephan Müller wrote: > > > A simple copy operation, however,

[PATCH 4.4 12/34] lib/mpi: Fix umul_ppmm() for MIPS64r6

4.4-stable review patch. If anyone has any objections, please let me know. -- From: James Hogan [ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ] Current MIPS64r6 toolchains aren't able to generate efficient DMULU/DMUHU based code for the C

[PATCH 4.9 24/56] lib/mpi: Fix umul_ppmm() for MIPS64r6

4.9-stable review patch. If anyone has any objections, please let me know. -- From: James Hogan [ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ] Current MIPS64r6 toolchains aren't able to generate efficient DMULU/DMUHU based code for the C

[PATCH 4.14 050/115] lib/mpi: Fix umul_ppmm() for MIPS64r6

4.14-stable review patch. If anyone has any objections, please let me know. -- From: James Hogan [ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ] Current MIPS64r6 toolchains aren't able to generate efficient DMULU/DMUHU based code for the C