These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge
---
drivers/crypto/bcm/cipher.c | 1 -
drivers/crypto/cavium/nitrox/nitrox_reqmgr.c | 1 -
drivers/crypto/cc
This part of Secure Encrypted 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 (
The SEV_PLATFORM_STATUS command can be used by the platform owner to
get the current status of the platform. The command is defined in
SEV spec section 5.5.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
The SEV_FACTORY_RESET command can be used by the platform owner to
reset the non-volatile SEV related data. The command is defined in
SEV spec section 5.4
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
C
The Platform Security Processor (PSP) is part of the AMD Secure
Processor (AMD-SP) functionality. The PSP is a dedicated processor
that provides support for key management commands in Secure Encrypted
Virtualization (SEV) mode, along with software-based Trusted Execution
Environment (TEE) to enable
AMD's new Secure Encrypted Virtualization (SEV) feature allows the
memory contents of virtual machines to be transparently encrypted with a
key unique to the VM. The programming and management of the encryption
keys are handled by the AMD Secure Processor (AMD-SP) which exposes the
commands for the
Add a include file which defines the ioctl and command id used for
issuing SEV platform management specific commands.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: linux-ker
The SEV_PDH_GEN command is used to re-generate the Platform
Diffie-Hellman (PDH) key. The command is defined in SEV spec section
5.6.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.o
The SEV_PEK_CERT_IMPORT command can be used to import the signed PEK
certificate. The command is defined in SEV spec section 5.8.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
C
The SEV_PEK_CSR command can be used to generate a PEK certificate
signing request. The command is defined in SEV spec section 5.7.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
From: Borislav Petkov
This is AMD-specific hardware so present it in Kconfig only when AMD
CPU support is enabled or on ARM64 where it is also used.
Signed-off-by: Borislav Petkov
Signed-off-by: Brijesh Singh
Reviewed-by: Gary R Hook
Cc: Brijesh Singh
Cc: Tom Lendacky
Cc: Gary Hook
Cc: Her
The SEV_PDH_CERT_EXPORT command can be used to export the PDH and its
certificate chain. The command is defined in SEV spec section 5.10.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kern
The SEV_PEK_GEN command is used to generate a new Platform Endorsement
Key (PEK). The command is defined in SEV spec section 5.6.
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Hook
Cc: Tom Lendacky
Cc: linux-crypto@vger.kernel.org
Cc: k...@vger.kernel.org
C
Define Secure Encrypted Virtualization (SEV) key management command id
and structure. The command definition is available in SEV KM spec
0.14 (http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf)
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Borislav Petkov
Cc: Herbert Xu
Cc: Gary Ho
On Mon, Dec 04, 2017 at 01:53:49PM +0100, Łukasz Stelmach wrote:
> Add binding documentation for the True Random Number Generator
> found on Samsung Exynos 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> .../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17
> +
>
Hello,
On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote:
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index d04ec3b..e09f035 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -30,7 +30,6 @@
> #include
> #include
On Mon, Dec 04, 2017 at 03:19:39AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Unit Testing:
>
> - build successful
> - LTP testsuite passes.
> - checkpatch.pl pas
On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> MAINTAINERS | 7 +
> drivers/char/hw_random/Kconfig | 12 ++
> drivers/char/hw_
On Mon, Dec 4, 2017 at 1:53 PM, Łukasz Stelmach wrote:
> Add binding documentation for the True Random Number Generator
> found on Samsung Exynos 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> .../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17
> +
> 1 file cha
Add binding documentation for the True Random Number Generator
found on Samsung Exynos 5250+ SoCs.
Signed-off-by: Łukasz Stelmach
---
.../devicetree/bindings/rng/samsung,exynos5250-trng.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bin
Hello.
The following patches add support for the true random number generator
found in Samsung Exynos 5250+ SoCs.
Patch #1 adds documentation for devicetree bindings.
Patch #2 introduces the driver and appropriate changes in Makefile and Kconfig.
Patch #3 adds nodes in devicetree files for Exyn
Add support for True Random Number Generator found in Samsung Exynos
5250+ SoCs.
Signed-off-by: Łukasz Stelmach
---
MAINTAINERS | 7 +
drivers/char/hw_random/Kconfig | 12 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/exynos-trng.c | 24
Add nodes for the True Random Number Generator found in Samsung Exynos
5250+ SoCs.
Signed-off-by: Łukasz Stelmach
---
arch/arm/boot/dts/exynos5.dtsi| 5 +
arch/arm/boot/dts/exynos5250.dtsi | 5 +
arch/arm/boot/dts/exynos5410.dtsi | 5 +
arch/arm/boot/dts/exynos5420.dtsi | 5 +
Avoid excessive scheduling delays under a preemptible kernel by
yielding the NEON every 8 blocks of input.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crct10dif-ce-core.S | 39 ++--
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/crypto/crct10dif
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
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
b/arch/arm64/
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 co
This updates both the core GHASH as well as the AES-GCM algorithm to
yield each time after processing a fixed chunk of input. For the GCM
driver, we align with the other AES/CE block mode drivers, and use
a block size of 64 bytes. The core GHASH is much shorter, so let's
use a block size of 128 byt
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 routines
Avoid excessive scheduling delays under a preemptible kernel by
yielding the NEON every 16 blocks of input.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crc32-ce-core.S | 55 +++-
1 file changed, 43 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/crypto/crc32-ce-co
Currently, the bit-sliced AES code may keep preemption disabled for as
long as it takes to process each contigous chunk of input, which could
be as large as a page or skb, depending on the context.
For this code to be useable in RT context, it needs to operate on fixed
chunks of limited size. So l
Currently, the AES block code may keep preemption disabled for as long
as it takes to process each contigous chunk of input, which could be as
large as a page or skb, depending on the context.
For this code to be useable in RT context, it needs to operate on fixed
chunks of limited size. So let's
Avoid excessive scheduling delays under a preemptible kernel by
yielding the NEON every 8 blocks of input.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha2-ce-core.S | 40 ++--
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/crypto/sha2-ce-core.
Avoid excessive scheduling delays under a preemptible kernel by
yielding the NEON every 8 blocks of input.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha1-ce-core.S | 45 ++--
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-core.
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 tha
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 tha
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 tha
Add a support macro to conditionally yield the NEON (and thus the CPU)
that may be called from the assembler code. Given that especially the
instruction based accelerated crypto code may use very tight loops, add
some parametrization so that the TIF_NEED_RESCHED flag test is only
executed every so
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 INTERL
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 tha
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 tha
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
---
crypto/tes
This is a followup 'crypto: arm64 - disable NEON across scatterwalk API
calls' sent out last Friday.
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 skciph
Hello Atul Gupta,
The patch 6dad4e8ab3ec: "chcr: Add support for Inline IPSec" from Nov
16, 2017, leads to the following static checker warning:
drivers/crypto/chelsio/chcr_ipsec.c:431 copy_key_cpltx_pktxt()
warn: potential pointer math issue ('q->q.desc' is a 512 bit pointer)
dr
On Sun, Dec 03, 2017 at 01:58:12PM +, Gilad Ben-Yossef wrote:
> The ccree drivers was marking a lot of big functions in C file as
> static inline for no good reason. Remove the inline qualifier from
> any but the few truly single line functions.
>
The compiler is free to ignore inline hints..
Looks good. Thanks!
regards,
dan carpenter
On 2 December 2017 at 13:59, Peter Zijlstra wrote:
> On Sat, Dec 02, 2017 at 11:15:14AM +, Ard Biesheuvel wrote:
>> On 2 December 2017 at 09:11, Ard Biesheuvel
>> wrote:
>
>> > They consume the entire input in a single go, yes. But making it more
>> > granular than that is going to hurt perf
47 matches
Mail list logo