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

[RFC PATCH] crypto: pcrypt - forbid recursive instantiation

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 submitted. That is, the inner pcrypt request waits for the outer

[PATCH v3 6/6] 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 v3 5/6] trusted keys: Add session encryption protection to the seal/unseal path

If some entity is snooping the TPM bus, the can see the data going in to be sealed and the data coming out as it is unsealed. Add parameter and response encryption to these cases to ensure that no secrets are leaked even if the bus is snooped. As part of doing this conversion it was discovered

[PATCH v3 4/6] tpm2: add session encryption protection to tpm2_get_random()

If some entity is snooping the TPM bus, they can see the random numbers we're extracting from the TPM and do prediction attacks against their consumers. Foil this attack by using response encryption to prevent the attacker from seeing the random sequence. Signed-off-by: James Bottomley

[PATCH v3 3/6] tpm2: add hmac checks to tpm2_pcr_extend()

We use tpm2_pcr_extend() in trusted keys to extend a PCR to prevent a key from being re-loaded until the next reboot. To use this functionality securely, that extend must be protected by a session hmac. Signed-off-by: James Bottomley --- v3: add error

[PATCH v3 2/6] 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

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

This separates out the old tpm_buf_... handling functions from static inlines into tpm.h and makes them their own tpm-buf.c file. It also adds handling for tpm2b structures and also incremental pointer advancing parsers. Signed-off-by: James Bottomley ---

[PATCH v3 0/6] 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: [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

[PATCH v5 08/23] crypto: arm64/aes-blk - add 4 way interleave to CBC-MAC encrypt path

CBC MAC is strictly sequential, and so the current AES code simply processes the input one block at a time. However, we are about to add yield support, which adds a bit of overhead, and which we prefer to align with other modes in terms of granularity (i.e., it is better to have all routines yield

[PATCH v5 23/23] DO NOT MERGE

Test code to force a kernel_neon_end+begin sequence at every yield point, and wipe the entire NEON state before resuming the algorithm. --- arch/arm64/include/asm/assembler.h | 33 1 file changed, 33 insertions(+) diff --git a/arch/arm64/include/asm/assembler.h

[PATCH v5 11/23] arm64: assembler: add macros to conditionally yield the NEON under PREEMPT

Add support macros to conditionally yield the NEON (and thus the CPU) that may be called from the assembler code. In some cases, yielding the NEON involves saving and restoring a non trivial amount of context (especially in the CRC folding algorithms), and so the macro is split into three, and

[PATCH v5 14/23] crypto: arm64/aes-ccm - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-ce-ccm-core.S | 150 +--- 1 file changed, 95 insertions(+), 55

[PATCH v5 20/23] crypto: arm64/sha3-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha3-ce-core.S | 77 +--- 1 file changed, 50 insertions(+), 27 deletions(-)

[PATCH v5 22/23] crypto: arm64/sm3-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sm3-ce-core.S | 30 +++- 1 file changed, 23 insertions(+), 7 deletions(-)

[PATCH v5 13/23] crypto: arm64/sha2-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha2-ce-core.S | 37 ++-- 1 file changed, 26 insertions(+), 11 deletions(-)

[PATCH v5 09/23] crypto: arm64/sha256-neon - play nice with CONFIG_PREEMPT kernels

Tweak the SHA256 update routines to invoke the SHA256 block transform block by block, to avoid excessive scheduling delays caused by the NEON algorithm running with preemption disabled. Also, remove a stale comment which no longer applies now that kernel mode NEON is actually disallowed in some

[PATCH v5 18/23] crypto: arm64/crc32-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crc32-ce-core.S | 40 +++- 1 file changed, 30 insertions(+), 10 deletions(-)

[PATCH v5 16/23] crypto: arm64/aes-bs - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-neonbs-core.S | 305 +++- 1 file changed, 170 insertions(+), 135

[PATCH v5 15/23] crypto: arm64/aes-blk - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/aes-ce.S| 15 +- arch/arm64/crypto/aes-modes.S | 331 2 files

[PATCH v5 12/23] crypto: arm64/sha1-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha1-ce-core.S | 42 ++-- 1 file changed, 29 insertions(+), 13 deletions(-)

[PATCH v5 10/23] arm64: assembler: add utility macros to push/pop stack frames

We are going to add code to all the NEON crypto routines that will turn them into non-leaf functions, so we need to manage the stack frames. To make this less tedious and error prone, add some macros that take the number of callee saved registers to preserve and the extra size to allocate in the

[PATCH v5 21/23] crypto: arm64/sha512-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/sha512-ce-core.S | 27 +++- 1 file changed, 21 insertions(+), 6 deletions(-)

[PATCH v5 19/23] crypto: arm64/crct10dif-ce - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/crct10dif-ce-core.S | 32 +--- 1 file changed, 28 insertions(+), 4

[PATCH v5 17/23] crypto: arm64/aes-ghash - yield NEON after every block of input

Avoid excessive scheduling delays under a preemptible kernel by conditionally yielding the NEON after every block of input. Signed-off-by: Ard Biesheuvel --- arch/arm64/crypto/ghash-ce-core.S | 113 ++-- arch/arm64/crypto/ghash-ce-glue.c | 28 +++-- 2

[PATCH v5 01/23] crypto: testmgr - add a new test case for CRC-T10DIF

In order to be able to test yield support under preempt, add a test vector for CRC-T10DIF that is long enough to take multiple iterations (and thus possible preemption between them) of the primary loop of the accelerated x86 and arm64 implementations. Signed-off-by: Ard Biesheuvel

[PATCH v5 02/23] crypto: arm64/aes-ce-ccm - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v5 04/23] crypto: arm64/aes-bs - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v5 03/23] crypto: arm64/aes-blk - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

[PATCH v5 07/23] crypto: arm64/aes-blk - add 4 way interleave to CBC encrypt path

CBC encryption is strictly sequential, and so the current AES code simply processes the input one block at a time. However, we are about to add yield support, which adds a bit of overhead, and which we prefer to align with other modes in terms of granularity (i.e., it is better to have all

[PATCH v5 06/23] crypto: arm64/aes-blk - remove configurable interleave

The AES block mode implementation using Crypto Extensions or plain NEON was written before real hardware existed, and so its interleave factor was made build time configurable (as well as an option to instantiate all interleaved sequences inline rather than as subroutines) We ended up using

[PATCH v5 05/23] crypto: arm64/chacha20 - move kernel mode neon en/disable into loop

When kernel mode NEON was first introduced on arm64, the preserve and restore of the userland NEON state was completely unoptimized, and involved saving all registers on each call to kernel_neon_begin(), and restoring them on each call to kernel_neon_end(). For this reason, the NEON crypto code

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

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 free temporary buffers it uses to present the input and output arrays to

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