[PATCH] crypto: ccp: Check for NULL PSP pointer at module unload

field in the sp_device struct in psp_dev_destroy() and return immediately if it is NULL. Cc: # 4.16.x- Fixes: 2a6170dfe755 ("crypto: ccp: Add Platform Security Processor (PSP) device support") Signed-off-by: Tom Lendacky --- drivers/crypto/ccp/psp-dev.c |3 +++ 1 file changed, 3

[PATCH v1 5/5] crypto: ccp: Add support for new CCP/PSP device ID

Add a new CCP/PSP PCI device ID and new PSP register offsets. Signed-off-by: Tom Lendacky --- drivers/crypto/ccp/sp-pci.c | 29 - 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c index 78c1e9d

[PATCH v1 4/5] crypto: ccp: Support register differences between PSP devices

In preparation for adding a new PSP device ID that uses different register offsets, add support to the PSP version data for register offset values. And then update the code to use these new register offset values. Signed-off-by: Tom Lendacky --- drivers/crypto/ccp/psp-dev.c | 24

[PATCH v1 3/5] crypto: ccp: Remove unused #defines

Remove some unused #defines for register offsets that are not used. This will lessen the changes required when register offsets change between versions of the device. Signed-off-by: Tom Lendacky --- drivers/crypto/ccp/psp-dev.c |2 +- drivers/crypto/ccp/psp-dev.h | 10 +- 2 files

[PATCH v1 1/5] crypto: ccp: Fix command completion detection race

with the interrupt handler and result in the wait_event() never returning. Move the initialization of the wait condition variable to just before command submission. Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Cc: # 4.16.x- Signed-off-by: To

[PATCH v1 2/5] crypto: ccp: Add psp enabled message when initialization succeeds

Add a dev_notice() message to the PSP initialization to report when the PSP initialization has succeeded and the PSP is enabled. Signed-off-by: Tom Lendacky --- drivers/crypto/ccp/psp-dev.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/ccp/psp-dev.c b/drivers/crypto

[PATCH v1 0/5] crypto: ccp - Driver updates 2018-07-03

on cryptodev-2.6. --- Tom Lendacky (5): crypto: ccp: Fix command completion detection race crypto: ccp: Add psp enabled message when initialization succeeds crypto: ccp: Remove unused #defines crypto: ccp: Support register differences between PSP devices crypto: ccp: Add

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

On 3/6/2018 5:45 AM, Kamil Konieczny wrote: > Prevent improper use of req->digest field in ahash update, init, export and Shouldn't that be req->result (here and below)? Thanks, Tom > import functions in drivers code. A driver should use ahash request context > if it needs to save internal

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: don't disable interrupts while setting up debugfs

On 2/25/2018 8:04 PM, Hook, Gary wrote: > On 2/23/2018 5:33 PM, 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: > > There is more than one CCP on some processors. The

Re: [Part2 PATCH v5.1 12.1/31] crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support

On 10/10/2017 10:00 AM, Brijesh Singh wrote: On 10/09/2017 10:21 AM, Borislav Petkov wrote: ... 03:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1468 13:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Device 1456 Btw, what do those PCI functions

Re: [PATCH v2 3/4] crypto: ccp - Rework the unit-size check for XTS-AES

Author: Gary R Hook <gary.h...@amd.com> * Author: Tom Lendacky <thomas.lenda...@amd.com> * * This program is free software; you can redistribute it and/or modify @@ -38,46 +39,26 @@ struct ccp_unit_size_map { u32 value; }; -static struct ccp_unit_size_map unit_size_

Re: [PATCH v2 2/4] crypto: ccp - Enable XTS-AES-128 support on all CCPs

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

Re: [PATCH] crypto: ccp - Fix XTS-AES support on a version 5 CCP

* AMD Cryptographic Coprocessor (CCP) AES XTS crypto API support * - * Copyright (C) 2013 Advanced Micro Devices, Inc. + * Copyright (C) 2013,2017 Advanced Micro Devices, Inc. * * Author: Tom Lendacky <thomas.lenda...@amd.com> * @@ -37,46 +37,26 @@ struct ccp_unit_size_map {

Re: [PATCH v2 2/3] crypto: ccp - Introduce the AMD Secure Processor device

On 6/28/2017 3:26 PM, Brijesh Singh wrote: On 06/28/2017 02:53 PM, Tom Lendacky wrote: In this I am leaving the top level config as-is and adding CONFIG_CRYPTO_DEV_SP_CCP to enable the CCP device support inside the SP device driver. [*] Support for AMD Secure Processor Secure Processor

Re: [PATCH v2 2/3] crypto: ccp - Introduce the AMD Secure Processor device

On 6/28/2017 2:39 PM, Brijesh Singh wrote: On 06/28/2017 12:47 PM, Tom Lendacky wrote: diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 0528a62..418f991 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -512,14 +512,14 @@ config CRYPTO_DEV_ATMEL_SHA

Re: [PATCH v2 2/3] crypto: ccp - Introduce the AMD Secure Processor device

On 6/23/2017 11:06 AM, Brijesh Singh wrote: The CCP device is part of the AMD Secure Processor. In order to expand the usage of the AMD Secure Processor, create a framework that allows functional components of the AMD Secure Processor to be initialized and handled appropriately. Signed-off-by:

Re: [PATCH 2] crypto: ccp - Provide a roll-back method for debugfs setup

On 6/27/2017 8:57 AM, Gary R Hook wrote: Changes since v1: - Remove unneeded local variable Signed-off-by: Gary R Hook --- drivers/crypto/ccp/ccp-debugfs.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git

Re: [PATCH v2 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

On 6/23/2017 11:06 AM, Brijesh Singh wrote: Update pci and platform files to use devres interface to allocate the PCI and iomap resources. Also add helper functions to consolicate module init, exit and power mangagement code duplication. Signed-off-by: Brijesh Singh ---

Re: [PATCH 4/4] crypto: ccp - Expand RSA support for a v5 ccp

On 6/21/2017 5:48 PM, Gary R Hook wrote: A V5 device can accommodate larger keys, as well as read the keys directly from memory instead of requiring them to be in a local storage block. The previous patch already reads them from memory so just the first part of this sentence is needed.

Re: [PATCH 3/4] crypto: ccp - Add support for RSA on the CCP

On 6/21/2017 5:48 PM, Gary R Hook wrote: Wire up the v3 CCP as a cipher provider. The V5 support will be invoked through this also. Maybe something like: Wire up the CCP as an RSA cipher provider. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/Makefile |

Re: [PATCH 1/4] crypto: ccp - Fix base RSA function for version 5 CCPs

On 6/21/2017 5:47 PM, Gary R Hook wrote: Version 5 devices have requirements for buffer lengths, as well as parameter format (e.g. bits vs. bytes). Fix the base CCP driver code to meet requirements all supported versions. Signed-off-by: Gary R Hook ---

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On 3/16/2017 3:04 PM, Tom Lendacky wrote: On 3/7/2017 8:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: From: Tom Lendacky <thomas.lenda...@amd.com> In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On 3/17/2017 9:32 AM, Tom Lendacky wrote: On 3/16/2017 3:04 PM, Tom Lendacky wrote: On 3/7/2017 8:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: From: Tom Lendacky <thomas.lenda...@amd.com> In order for memory pages to be properly mapped wh

Re: [RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

On 3/7/2017 8:59 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:13:32AM -0500, Brijesh Singh wrote: From: Tom Lendacky <thomas.lenda...@amd.com> In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base prot

Re: [RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

On 3/7/2017 5:09 AM, Borislav Petkov wrote: On Thu, Mar 02, 2017 at 10:12:59AM -0500, Brijesh Singh wrote: From: Tom Lendacky <thomas.lenda...@amd.com> When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as EFI related data, setup data) is encrypted and needs to be ac

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On 3/16/2017 10:09 AM, Borislav Petkov wrote: On Thu, Mar 16, 2017 at 09:28:58AM -0500, Tom Lendacky wrote: Because there are differences between how SME and SEV behave (instruction fetches are always decrypted under SEV, DMA to an encrypted location is not supported under SEV, etc.) we need

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

On 3/16/2017 5:16 AM, Borislav Petkov wrote: On Fri, Mar 10, 2017 at 10:35:30AM -0600, Brijesh Singh wrote: We could update this patch to use the below logic: * CPUID(0) - Check for AuthenticAMD * CPID(1) - Check if under hypervisor * CPUID(0x8000) - Check for highest supported leaf *

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On 3/6/2017 6:03 PM, Bjorn Helgaas wrote: On Fri, Mar 03, 2017 at 03:15:34PM -0600, Tom Lendacky wrote: On 3/3/2017 2:42 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: From: Tom Lendacky <thomas.lenda...@amd.com> The use of ioremap will

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

On 3/3/2017 2:42 PM, Bjorn Helgaas wrote: On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote: From: Tom Lendacky <thomas.lenda...@amd.com> The use of ioremap will force the setup data to be mapped decrypted even though setup data is encrypted. Switch to using memremap

Re: [PATCH 2/6] crypto: ccp - Remove unneeded sign-extension support

On 10/13/2016 09:53 AM, Gary R Hook wrote: > The reverse-get/set functions can be simplified by > eliminating unused code. > > > Signed-off-by: Gary R Hook > --- > drivers/crypto/ccp/ccp-ops.c | 145 > +- > 1 file changed, 59

Re: [PATCH 6/6] crypto: ccp - Enable 3DES function on v5 CCPs

On 10/13/2016 09:53 AM, Gary R Hook wrote: > Wire up support for Triple DES in ECB mode. > > Signed-off-by: Gary R Hook > --- > drivers/crypto/ccp/Makefile |1 > drivers/crypto/ccp/ccp-crypto-des3.c | 254 > ++ >

Re: [PATCH 5/6] crypto: ccp - Enable support for AES GCM on v5 CCPs

t; index 000..5da324f > --- /dev/null > +++ b/drivers/crypto/ccp/ccp-crypto-aes-galois.c > @@ -0,0 +1,252 @@ > +/* > + * AMD Cryptographic Coprocessor (CCP) AES crypto API support > + * > + * Copyright (C) 2013,2016 Advanced Micro Devices, Inc. > + * > + * Author: Tom

Re: [PATCH 3/6] crypto: ccp - Add support for RSA on the CCP

On 10/13/2016 09:53 AM, Gary R Hook wrote: > Wire up the v3 CCP as a cipher provider. > > Signed-off-by: Gary R Hook > --- > drivers/crypto/ccp/Makefile |1 > drivers/crypto/ccp/ccp-crypto-main.c | 15 ++ > drivers/crypto/ccp/ccp-crypto-rsa.c | 258 >

Re: [PATCH 1/6] crypto: ccp - Add SHA-2 support

On 10/13/2016 09:52 AM, Gary R Hook wrote: > Incorporate 384-bit and 512-bit hashing for a version 5 CCP > device > > > Signed-off-by: Gary R Hook > --- > drivers/crypto/ccp/ccp-crypto-sha.c | 22 +++ > drivers/crypto/ccp/ccp-crypto.h |9 +++-- >

Re: [PATCH 1/2] crypto: ccp - data structure cleanup

On 09/28/2016 10:49 AM, Gary R Hook wrote: > Change names of data structure instances; add const > keyword where appropriate. > > Signed-off-by: Gary R Hook > --- > drivers/crypto/ccp/ccp-dev-v3.c |2 +- > drivers/crypto/ccp/ccp-dev-v5.c |7 +-- >

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

On 09/22/2016 12:07 PM, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 05:05:54PM +0200, Paolo Bonzini wrote: >> Which paragraph? > > "Linux relies on BIOS to set this bit if BIOS has determined that the > reduction in the physical address space as a result of enabling memory > encryption..." >

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

On 09/22/2016 02:11 PM, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote: >> That's not what I mean here. If the BIOS sets the SMEE bit in the >> SYS_CFG msr then, even if the encryption bit is never used, there is >> still a reductio

Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active

On 09/22/2016 09:45 AM, Paolo Bonzini wrote: > > > On 22/09/2016 16:35, Borislav Petkov wrote: @@ -230,6 +230,10 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd); pgd = efi_pgd;

Re: [RFC PATCH v1 18/28] crypto: add AMD Platform Security Processor driver

erface for SEV guests. >> >> Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> >> Signed-off-by: Brijesh Singh <brijesh.si...@amd.com> > > This driver doesn't seem to hook into the Crypto API at all, is > there any reason why it should be in drivers/crypto?

Re: [PATCH] crypto: ccp - Fix AES XTS error for request sizes above 4096

On 05/20/2016 06:35 PM, Herbert Xu wrote: > On Fri, May 20, 2016 at 05:33:03PM -0500, Tom Lendacky wrote: >> The ccp-crypto module for AES XTS support has a bug that can allow requests >> greater than 4096 bytes in size to be passed to the CCP hardware. The CCP >> hardware doe

[PATCH] crypto: ccp - Fix AES XTS error for request sizes above 4096

mechanism instantiated by the ccp-crypto module. Add a check to insure the request size is less than or equal to the maximum supported size and use the fallback mechanism if it is not. Cc: <sta...@vger.kernel.org> # 3.14.x- Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- driver

Re: [PATCH] crypto/ccp: remove rwlocks_types.h

On 05/11/2016 05:06 AM, Sebastian Andrzej Siewior wrote: > Users of rwlocks should include spinlock.h instead including this > header file. The current users of rwlocks_types.h are internal. > > Signed-off-by: Sebastian Andrzej Siewior There's already been a patch

[PATCH] crypto: ccp - Prevent information leakage on export

y: Ben Hutchings <b...@decadent.org.uk> Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c |3 +++ drivers/crypto/ccp/ccp-crypto-sha.c |3 +++ 2 files changed, 6 insertions(+) diff --git a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c b/

Re: [PATCH] crypto: ccp - Register the CCP as a DMA resource

> int ccp_run_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd); > > +int ccp_dmaengine_register(struct ccp_device *ccp); > +void ccp_dmaengine_unregister(struct ccp_device *ccp); > + > #endif > diff --git a/drivers/crypto/ccp/ccp-dmaengine.c > b/drivers/crypto/ccp

[PATCH] MAINTAINERS: Add a new maintainer for the CCP driver

Gary will be taking over future development of the CCP driver, so add him as a co-maintainer of the driver. Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 30aca4a..8c42c07

Re: [PATCH] crypto: ccp - Use different flag vars for nested locks

On 03/11/2016 10:40 AM, Gary R Hook wrote: > This patch fixes a coccinelle warning about reusing a flags > variable in nested lock acquisition. > > Signed-off-by: Gary R Hook <gary.h...@amd.com> Acked-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > drive

Re: [PATCH 3/4] crypto: ccp - CCP versioning support

; and registers algorithms accordingly. A structure is added > which manages the version-specific data. > > Signed-off-by: Gary R Hook <gary.h...@amd.com> Acked-by: Tom Lendacky <thomas.lenda...@amd.com> > --- > drivers/crypto/ccp/ccp-crypto-aes.c | 12 ++- >

Re: [PATCH 1/4] crypto: ccp - Remove check for x86 family and model

On 03/01/2016 01:48 PM, Gary R Hook wrote: > Each x86 SoC will make use of a unique PCI ID for the CCP > device so it is not necessary to check for the CPU family > and model. > > Signed-off-by: Gary R Hook <gary.h...@amd.com> Acked-by: Tom Lendacky <thomas.lenda...@am

[PATCH] crypto: ccp - memset request context to zero during import

sta...@vger.kernel.org> # 3.14.x- Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c |1 + drivers/crypto/ccp/ccp-crypto-sha.c |1 + 2 files changed, 2 insertions(+) diff --git a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c b/driver

Re: Is a crypto_ahash_init required before invoking crypto_ahash_import?

On 02/25/2016 04:11 PM, Herbert Xu wrote: > On Thu, Feb 25, 2016 at 03:56:31PM -0600, Tom Lendacky wrote: >> >> I can fix this in the driver by doing a memset to zero of the request >> context area during the import. But I guess I'm also wondering if there >> is

Is a crypto_ahash_init required before invoking crypto_ahash_import?

I'm seeing an issue on one system that I wasn't seeing on another system. It turns out that the testmgr sha testing exports an ahash request context, allocates a new ahash request context and then imports into that new ahash request context. Since crypto_ahash_init() is not performed the driver

[PATCH v1] crypto: ccp - Don't assume export/import areas are aligned

and then use the local variable to set the request context. Cc: <sta...@vger.kernel.org> # 3.14.x- Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 26 +- drivers/crypto/ccp/ccp-crypto-sha.c

Re: [PATCH v1] crypto: ccp - Limit the amount of information exported

On 02/01/2016 08:35 AM, Herbert Xu wrote: > On Fri, Jan 29, 2016 at 12:45:14PM -0600, Tom Lendacky wrote: >> Since the exported information can be exposed to user-space, instead of >> exporting the entire request context only export the minimum information >> n

[PATCH v1] crypto: ccp - Limit the amount of information exported

Since the exported information can be exposed to user-space, instead of exporting the entire request context only export the minimum information needed. Cc: <sta...@vger.kernel.org> # 3.14.x- Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- drivers/crypto/ccp/ccp-crypt

Re: [PATCH v1] crypto: ccp - Add hash state import and export support

On 01/12/2016 11:17 AM, Tom Lendacky wrote: > Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") > added a check to prevent ahash algorithms from successfully registering > if the import and export functions were not implemented. This prevents > an o

Re: [PATCH 3/8] crypto: ccp: Use precalculated hash from headers

On 10/20/2015 02:33 AM, LABBE Corentin wrote: Precalculated hash for empty message are now present in hash headers. This patch just use them. Signed-off-by: LABBE Corentin <clabbe.montj...@gmail.com> Tested-by: Tom Lendacky <thomas.lenda...@amd.com> Acked-by: Tom Lendacky &

Re: [PATCH 3/8] crypto: ccp: Use precalculated hash from headers

On 10/12/2015 11:53 AM, LABBE Corentin wrote: Precalculated hash for empty message are now present in hash headers. This patch just use them. Signed-off-by: LABBE Corentin <clabbe.montj...@gmail.com> Just a minor comment below. Tested-by: Tom Lendacky <thomas.lenda...@amd.com> A

[PATCH v1 0/4] crypto: ccp - CCP driver updates 2015-10-01

This patch series is based on cryptodev-2.6. --- Tom Lendacky (4): crypto: ccp - Replace BUG_ON with WARN_ON and a return code crypto: ccp - Remove use ACPI field crypto: ccp - Change references to accelerator to offload crypto: ccp - Use module name in driver structures

[PATCH v1 3/4] crypto: ccp - Change references to accelerator to offload

The CCP is meant to be more of an offload engine than an accelerator engine. To avoid any confusion, change references to accelerator to offload. Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- drivers/crypto/Kconfig |2 +- drivers/crypto/ccp/Kconfig | 13 ++

[PATCH v1 4/4] crypto: ccp - Use module name in driver structures

The convention is to use the name of the module in the driver structures that are used for registering the device. The CCP module is currently using a descriptive name. Replace the descriptive name with module name. Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- drivers/crypto/c

[PATCH v1 1/4] crypto: ccp - Replace BUG_ON with WARN_ON and a return code

Replace the usage of BUG_ON with WARN_ON and return an error. Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 20 +- drivers/crypto/ccp/ccp-crypto-main.c |6 +- drivers/crypto/ccp/ccp-crypto-sha.c | 13 drivers/

Re: [PATCH v2 5/8] lib: introduce sg_nents_len_chained

On 09/18/2015 07:57 AM, LABBE Corentin wrote: Some driver use a modified version of sg_nents_for_len with an additional parameter bool *chained for knowing if the scatterlist is chained or not. So, for removing duplicate code, add sg_nents_len_chained in lib/scatterlist.c Signed-off-by: LABBE

[PATCH v1 1/2] scatterlist: introduce sg_nents_for_len

to the dma_map_sg() call to successfully map the sg. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- include/linux/scatterlist.h |1 + lib/scatterlist.c | 32 2 files changed, 33 insertions(+) diff --git a/include/linux/scatterlist.h b/include/linux

[PATCH v1 2/2] crypto: ccp - Protect against poorly marked end of sg list

() function which returns only the number of sg entries required to meet the desired length and supplying that value to dma_map_sg(). Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-ops.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v1 3/3] crypto: ccp - Protect against poorly marked end of sg list

On 05/27/2015 07:36 PM, Herbert Xu wrote: On Wed, May 27, 2015 at 09:12:02AM -0500, Tom Lendacky wrote: The reason I'm asking is because while this patch fixes your driver everybody else will still crash and burn should something like this happen again. A number of other drivers already

Re: [PATCH v1 3/3] crypto: ccp - Protect against poorly marked end of sg list

On 05/27/2015 04:43 AM, Herbert Xu wrote: Tom Lendacky thomas.lenda...@amd.com wrote: Scatter gather lists can be created with more available entries than are actually used (e.g. using sg_init_table() to reserve a specific number of sg entries, but in actuality using something less than

Re: [PATCH v1 3/3] crypto: ccp - Protect against poorly marked end of sg list

On 05/27/2015 04:45 AM, Herbert Xu wrote: On Wed, May 27, 2015 at 05:43:05PM +0800, Herbert Xu wrote: Tom Lendacky thomas.lenda...@amd.com wrote: Scatter gather lists can be created with more available entries than are actually used (e.g. using sg_init_table() to reserve a specific number

[PATCH v1 0/3] crypto: ccp - CCP driver updates 2015-05-26

on cryptodev-2.6. --- Tom Lendacky (3): crypto: ccp - Remove manual check and set of dma_mask pointer crypto: ccp - Remove unused structure field crypto: ccp - Protect against poorly marked end of sg list drivers/crypto/ccp/ccp-ops.c | 20 +--- drivers/crypto/ccp

[PATCH v1 2/3] crypto: ccp - Remove unused structure field

Remove the length field from the ccp_sg_workarea since it is unused. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-ops.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c index 71f2e3c..542453c

[PATCH v1 1/3] crypto: ccp - Remove manual check and set of dma_mask pointer

The underlying device support will set the device dma_mask pointer if DMA is set up properly for the device. Remove the check for and assignment of dma_mask when it is null. Instead, just error out if the dma_set_mask_and_coherent function fails because dma_mask is null. Signed-off-by: Tom

[PATCH v1 3/3] crypto: ccp - Protect against poorly marked end of sg list

of sg entries needed to meet the length requirement and supplying that value to dma_map_sg(). Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-ops.c | 18 +- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/ccp/ccp-ops.c

Re: [Linaro-acpi] [V2 PATCH 2/5] arm64 : Introduce support for ACPI _CCA object

On 05/05/2015 11:13 AM, Suravee Suthikulanit wrote: On 5/5/2015 11:12 AM, Arnd Bergmann wrote: On Tuesday 05 May 2015 11:09:38 Suravee Suthikulanit wrote: However, codes in several places are making use of dma_map_ops without checking if the ops are NULL (i.e.

Re: [PATCH 4/4] crypto: talitos - add software backlog queue handling

On 03/13/2015 12:16 PM, Horia Geanta wrote: I was running into situations where the hardware FIFO was filling up, and the code was returning EAGAIN to dm-crypt and just dropping the submitted crypto request. This adds support in talitos for a software backlog queue. When requests can't be

Re: AF_ALG interface not marking the end of the scatter-gather list

On 02/13/2015 05:43 AM, Stephan Mueller wrote: Am Donnerstag, 12. Februar 2015, 17:41:59 schrieb Tom Lendacky: Hi Tom, I was doing some testing of the CCP driver using the AF_ALG interface and encountered a BUG_ON statement during scatter-gather DMA mapping. In algif_skcipher.c, before

AF_ALG interface not marking the end of the scatter-gather list

I was doing some testing of the CCP driver using the AF_ALG interface and encountered a BUG_ON statement during scatter-gather DMA mapping. In algif_skcipher.c, before submitting a request to the the Crypto API the input sg list is not updated to mark the last valid sg entry of the input data.

[PATCH v1 4/5] crypto: ccp - Convert calls to their devm_ counterparts

Where applicable, convert calls to their devm_ counterparts, e.g. kzalloc to devm_kzalloc. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-dev.c |2 +- drivers/crypto/ccp/ccp-pci.c | 19 +-- drivers/crypto/ccp/ccp-platform.c | 11

[PATCH v1 1/5] crypto: ccp - Updates for checkpatch warnings/errors

Changes to address warnings and errors reported by the checkpatch script. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 12 +++- drivers/crypto/ccp/ccp-crypto-aes-xts.c |4 +--- drivers/crypto/ccp/ccp-crypto-aes.c |3

[PATCH v1 2/5] crypto: ccp - Update CCP build support

Add HAS_IOMEM as a Kconfig dependency. Always include ccp-platform.c in the CCP build and conditionally include ccp-pci.c. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/Kconfig |2 +- drivers/crypto/ccp/Makefile |9 ++--- 2 files changed, 3 insertions

[PATCH v1 0/5] crypto: ccp - CCP driver updates 2015-01-28

dma_set_mask_and_coherent to set the DMA mask - Use devm_ calls where appropriate - Add ACPI support This patch series is based on cryptodev-2.6. --- Tom Lendacky (5): crypto: ccp - Updates for checkpatch warnings/errors crypto: ccp - Update CCP build support crypto: ccp - Use

[PATCH v1 3/5] crypto: ccp - Use dma_set_mask_and_coherent to set DMA mask

Replace the setting of the DMA masks with the dma_set_mask_and_coherent function call. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-platform.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/ccp/ccp-platform.c b

[PATCH v1 5/5] crypto: ccp - Add ACPI support

Add support for ACPI to the CCP platform driver. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/Kconfig|2 - drivers/crypto/ccp/ccp-platform.c | 96 +++-- 2 files changed, 93 insertions(+), 5 deletions(-) diff --git

Re: [PATCH] crypto: ccp: terminate ccp_support array with empty element

On 01/21/2015 09:06 AM, Andrey Ryabinin wrote: x86_match_cpu() expects array of x86_cpu_ids terminated with empty element. Signed-off-by: Andrey Ryabinin a.ryabi...@samsung.com Acked-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-dev.c | 1 + 1 file changed, 1

Asynchronous usage of PCOMPRESS

Hi Herbert, Is the PCOMPRESS algorithm supposed to support asynchronous implementations? In other words, are callers expected to handle the -EINPROGRESS or -EAGAIN return codes that can be returned by an asynchronous implementation? Or is it assumed that if the CRYPTO_ALG_ASYNC flag is not set

Re: [PATCH v2 01/11] crypto: Documentation - crypto API high level spec

On 11/03/2014 08:49 AM, Herbert Xu wrote: On Mon, Nov 03, 2014 at 03:18:29PM +0100, Stephan Mueller wrote: + * CRYPTO_ALG_TYPE_DIGEST Raw message digest + * CRYPTO_ALG_TYPE_HASHAlias for CRYPTO_ALG_TYPE_DIGEST + * CRYPTO_ALG_TYPE_SHASH Synchronous multi-block hash +

Re: [PATCH] crypto: ccp - Check for CCP before registering crypto algs

On 09/15/2014 06:47 AM, Herbert Xu wrote: On Fri, Sep 05, 2014 at 11:49:38PM +, Scot Doyle wrote: On Fri, 5 Sep 2014, Tom Lendacky wrote: If the ccp is built as a built-in module, then ccp-crypto (whether built as a module or a built-in module) will be able to load and it will register

Re: AF_ALG inadvertently disabled

On 09/04/2014 07:43 PM, Scot Doyle wrote: On a laptop without AMD's CCP, compiling 3.17-rc3 with # CONFIG_MODULES is not set CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_DEV_CCP=y CONFIG_CRYPTO_DEV_CCP_DD=y # CONFIG_CRYPTO_DEV_CCP_CRYPTO is not set the strace from a test

[PATCH] crypto: ccp - Check for CCP before registering crypto algs

by the registered crypto algorithms. Add an API, ccp_present(), that checks for the presence of a CCP on the system. The ccp-crypto module can use this to determine if it should register it's crypto alogorithms. Reported-by: Scot Doyle lkm...@scotdoyle.com Signed-off-by: Tom Lendacky thomas.lenda

[PATCH] crypto: ccp - Do not sign extend input data to CCP

The CCP hardware interprets all numbers as unsigned numbers, therefore sign extending input data is not valid. Modify the function calls for RSA and ECC to not perform sign extending. This patch is based on the cryptodev-2.6 kernel tree. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com

[PATCH] crypto: ccp - Remove select OF from Kconfig

fengguang...@intel.com Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/Kconfig |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig index 474382d..7639ffc 100644 --- a/drivers/crypto/ccp/Kconfig +++ b/drivers/crypto/ccp

[PATCH] crypto: ccp - Base AXI DMA cache settings on device tree

to assign the AXI DMA cache settings based on whether the dma-coherent property is present in the device node. If present, use settings that work with the caches. If not present, use settings that do not look at the caches. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- .../devicetree/bindings

[PATCH V1 2/3] crypto: ccp - CCP device bindings documentation

This patch provides the documentation of the device bindings for the AMD Cryptographic Coprocessor driver. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- .../devicetree/bindings/crypto/amd-ccp.txt | 16 1 file changed, 16 insertions(+) create mode 100644

[PATCH V1 0/3] crypto: ccp - arm64 platform support

The following series implements support for the CCP as a platform driver on ARM64. This patch series is based on the cryptodev-2.6 kernel tree. --- Tom Lendacky (3): crypto: ccp - Modify PCI support in prep for arm64 support crypto: ccp - CCP device bindings documentation

[PATCH V1 3/3] crypto: ccp - Add platform device support for arm64

Add support for the CCP on arm64 as a platform device. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/Kconfig|2 drivers/crypto/ccp/Makefile |5 + drivers/crypto/ccp/ccp-dev.c | 34 ++ drivers/crypto/ccp/ccp-dev.h |7

[PATCH V1 1/3] crypto: ccp - Modify PCI support in prep for arm64 support

Modify the PCI device support in prep for supporting the CCP as a platform device for arm64. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-dev.h |3 +-- drivers/crypto/ccp/ccp-pci.c | 39 ++- 2 files changed, 15

[PATCH 0/3] crypto: ccp - minor code fixes

insertions(+), 7 deletions(-) -- Tom Lendacky -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] crypto: ccp - Account for CCP backlog processing

When the crypto layer is able to queue up a command for processing by the CCP on the initial call to ccp_crypto_enqueue_request and the CCP returns -EBUSY, then if the backlog flag is not set the command needs to be freed and not added to the active command list. Signed-off-by: Tom Lendacky

[PATCH 1/3] crypto: ccp - Prevent a possible lost CCP command request

If a CCP command has been queued for processing at the crypto layer then, when dequeueing it for processing, the can backlog flag must be set so that the request isn't lost if the CCP backlog queue limit is reached. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp

Re: Fix ccp_run_passthru_cmd dma variable assignments

to be changed to 'dst'. I have no hardware to test this, so this is untested. Yes, this was a cut-and-paste error that was not discovered with my tests. I've updated my testcases and tested/verified this fix. Herbert, this should probably go through the cryptodev-2.6 tree right? Acked-by: Tom Lendacky

[PATCH 1/4] crypto: ccp - Allow for selective disablement of crypto API algorithms

Introduce module parameters that allow for disabling of a crypto algorithm by not registering the algorithm with the crypto API. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-crypto-main.c | 37 +++--- 1 file changed, 25 insertions

  1   2   >