On Sat, Jul 22, 2017 at 02:16:41PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 21, 2017 at 04:55:12PM +0200, Oliver Mangold wrote:
> > On 21.07.2017 16:47, Theodore Ts'o wrote:
> > > On Fri, Jul 21, 2017 at 01:39:13PM +0200, Oliver Mangold wrote:
> > > > Better, but obviously there is still much room
On 20-07-2017 16:02, Dan Carpenter wrote:
> Hello Harsh Jain,
>
> The patch 14c19b178a01: "crypto: chcr - Select device in Round Robin
> fashion" from Jun 15, 2017, leads to the following static checker
> warning:
>
> drivers/crypto/chelsio/chcr_core.c:163 chcr_uld_add()
> warn: overw
On Mon, Jul 24, 2017 at 06:09:56PM -0700, Megha Dey wrote:
>
> Under the skcipher interface, if both the outer and inner alg are async,
> there should not be any problem right? Currently I do not see any
> existing algorithms have both algorithms async.
That's because the purpose of cryptd is to t
On Tue, 2017-07-25 at 00:53 +, Dey, Megha wrote:
>
> -Original Message-
> From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
> Sent: Wednesday, July 19, 2017 12:02 AM
> To: Dey, Megha
> Cc: Tim Chen ; da...@davemloft.net;
> linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.o
AMDs new Secure Encrypted Virtualization (SEV) feature allows the memory
contents of a virtual machine to be transparently encrypted with a key
unique to the guest VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP), which exposes the
commands
Platform Security Processor (PSP) is part of AMD Secure Processor (AMD-SP),
PSP is a dedicated processor that provides the support for key management
commands in a Secure Encrypted Virtualiztion (SEV) mode, along with
software-based Tursted Executation Environment (TEE) to enable the
third-party tu
This part of Secure Encryted Virtualization (SEV) patch series focuses on KVM
changes required to create and manage SEV guests.
SEV is an extension to the AMD-V architecture which supports running encrypted
virtual machine (VMs) under the control of a hypervisor. Encrypted VMs have
their
pages (c
On 24 July 2017 at 17:57, Eric Biggers wrote:
> On Mon, Jul 24, 2017 at 07:59:43AM +0100, Ard Biesheuvel wrote:
>> On 18 July 2017 at 13:06, Ard Biesheuvel wrote:
>> > The generic AES driver uses 16 lookup tables of 1 KB each, and has
>> > encryption and decryption routines that are fully unrolle
On Mon, Jul 24, 2017 at 07:59:43AM +0100, Ard Biesheuvel wrote:
> On 18 July 2017 at 13:06, Ard Biesheuvel wrote:
> > The generic AES driver uses 16 lookup tables of 1 KB each, and has
> > encryption and decryption routines that are fully unrolled. Given how
> > the dependencies between this code
On Fri, Jul 21, 2017 at 10:01:42PM -0700, Haren Myneni wrote:
>
> This patch adds P9 NX support for 842 compression engine. Virtual
> Accelerator Switchboard (VAS) is used to access 842 engine on P9.
>
> For each NX engine per chip, setup receive window using
> vas_rx_win_open() which configures
On 7/21/2017 2:05 PM, Gary R Hook wrote:
The CCP supports a limited set of unit-size values. Change the check
for this parameter such that acceptable values match the enumeration.
Then clarify the conditions under which we must use the fallback
implementation.
Signed-off-by: Gary R Hook
---
d
On 7/21/2017 2:04 PM, Gary R Hook wrote:
Version 5 CCPs have some new requirements for XTS-AES: the type field
must be specified, and the key requires 512 bits, with each part
occupying 256 bits and padded with zeroes.
This appears to be a fix and not a feature. You need to send this as
a separ
For the final round, avoid the expanded and padded lookup tables
exported by the generic AES driver. Instead, for encryption, we can
perform byte loads from the same table we used for the inner rounds,
which will still be hot in the caches. For decryption, use the inverse
AES Sbox directly, which i
For the final round, avoid the expanded and padded lookup tables
exported by the generic AES driver. Instead, for encryption, we can
perform byte loads from the same table we used for the inner rounds,
which will still be hot in the caches. For decryption, use the inverse
AES Sbox directly, which i
Currently, the AES-GCM implementation for arm64 systems that support the
ARMv8 Crypto Extensions is based on the generic GCM module, which combines
the AES-CTR implementation using AES instructions with the PMULL based
GHASH driver. This is suboptimal, given the fact that the input data needs
to be
Implement a NEON fallback for systems that do support NEON but have
no support for the optional 64x64->128 polynomial multiplication
instruction that is part of the ARMv8 Crypto Extensions. It is based
on the paper "Fast Software Polynomial Multiplication on ARM Processors
Using the NEON Engine" by
Implement a NEON fallback for systems that do support NEON but have
no support for the optional 64x64->128 polynomial multiplication
instruction that is part of the ARMv8 Crypto Extensions. It is based
on the paper "Fast Software Polynomial Multiplication on ARM Processors
Using the NEON Engine" by
The arm64 kernel will shortly disallow nested kernel mode NEON, so
add a fallback to scalar code that can be invoked in that case.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig| 3 +-
arch/arm64/crypto/sha2-ce-glue.c | 30 +---
arch/arm64/crypto/sha256-glue
The arm64 kernel will shortly disallow nested kernel mode NEON, so
add a fallback to scalar C code that can be invoked in that case.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 3 +-
arch/arm64/crypto/ghash-ce-glue.c | 49
2 files changed, 43 inser
The arm64 kernel will shortly disallow nested kernel mode NEON, so
add a fallback to scalar code that can be invoked in that case.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 1 +
arch/arm64/crypto/aes-ce-cipher.c | 20 +---
2 files changed, 18 insertio
The arm64 kernel will shortly disallow nested kernel mode NEON, so
add a fallback to scalar C code that can be invoked in that case.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig| 3 ++-
arch/arm64/crypto/sha1-ce-glue.c | 18 ++
2 files changed, 16 insertio
The arm64 kernel will shortly disallow nested kernel mode NEON, so
add a fallback to scalar C code that can be invoked in that case.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crct10dif-ce-glue.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm6
To accommodate systems that may disallow use of the NEON in kernel mode
in some circumstances, introduce a C fallback for synchronous AES in CTR
mode, and use it if may_use_simd() returns false.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig| 6 +-
arch/arm64/crypto/aes
To accommodate systems that disallow the use of kernel mode NEON in
some circumstances, take the return value of may_use_simd into
account when deciding whether to invoke the C fallback routine.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/chacha20-neon-glue.c | 5 +++--
1 file changed, 3
There are quite a number of occurrences in the kernel of the pattern
if (dst != src)
memcpy(dst, src, walk.total % AES_BLOCK_SIZE);
crypto_xor(dst, final, walk.total % AES_BLOCK_SIZE);
or
crypto_xor(keystream, src, nbytes);
memcpy(dst, keystream, nbytes);
where crypto_xor() is
The arm64 kernel will shortly disallow nested kernel mode NEON, so
add a fallback to scalar C code that can be invoked in that case.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crc32-ce-glue.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/cryp
In order to be able to reuse the generic AES code as a fallback for
situations where the NEON may not be used, update the key handling
to match the byte order of the generic code: it stores round keys
as sequences of 32-bit quantities rather than streams of bytes, and
so our code needs to be update
Of the various chaining modes implemented by the bit sliced AES driver,
only CTR is exposed as a synchronous cipher, and requires a fallback in
order to remain usable once we update the kernel mode NEON handling logic
to disallow nested use. So wire up the existing CTR fallback C code.
Signed-off-
In preparation of introducing crypto_xor_cpy(), which will use separate
operands for input and output, modify the __crypto_xor() implementation,
which it will share with the existing crypto_xor(), which provides the
actual functionality when not using the inline version.
Signed-off-by: Ard Biesheu
This is a resend of all the patches I sent out recently that I would
like to be considered for v4.14. Their main purpose is to prepare the
arm64 crypto code to deal with situations where the SIMD register file
is unavailable, which never occurs at present, but this will change in
the future when su
The arm64 kernel will shortly disallow nested kernel mode NEON.
So honour this in the ARMv8 Crypto Extensions implementation of
CCM-AES, and fall back to a scalar implementation using the generic
crypto helpers for AES, XOR and incrementing the CTR counter.
Signed-off-by: Ard Biesheuvel
---
arc
This series adds a driver for the crypto accelerator in the ARTPEC series of
SoCs from Axis Communications AB.
Changelog v2:
- Use xts_check_key() for xts keys.
- Use CRYPTO_ALG_TYPE_SKCIPHER instead of CRYPTO_ALG_TYPE_ABLKCIPHER
in cra_flags.
Lars Persson (3):
dt-bindings: crypto: add ARTPEC
From: Rabin Vincent
There are already helpers to (un)register multiple normal
and AEAD algos. Add one for ahashes too.
Signed-off-by: Lars Persson
---
crypto/ahash.c | 29 +
include/crypto/internal/hash.h | 2 ++
2 files changed, 31 insertions(+)
Assign the Axis kernel team as maintainer for crypto drivers under
drivers/crypto/axis.
Signed-off-by: Lars Persson
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d5b6c71e783e..72186cf9820d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1129,6
This is an asynchronous crypto API driver for the accelerator present
in the ARTPEC-6 and -7 SoCs from Axis Communications AB.
The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash
standards.
Signed-off-by: Lars Persson
---
drivers/crypto/Kconfig | 21 +
drivers/c
Document the device tree bindings for the ARTPEC crypto accelerator on
ARTPEC-6 and ARTPEC-7 SoCs.
Signed-off-by: Lars Persson
---
.../devicetree/bindings/crypto/artpec6-crypto.txt| 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/binding
On 18 July 2017 at 13:06, Ard Biesheuvel wrote:
> The generic AES driver uses 16 lookup tables of 1 KB each, and has
> encryption and decryption routines that are fully unrolled. Given how
> the dependencies between this code and other drivers are declared in
> Kconfig files, this code is always p
37 matches
Mail list logo
