On 4/15/21 11:09 AM, Paolo Bonzini wrote:
> On 07/04/21 20:00, Tom Lendacky wrote:
>> For the series:
>>
>> Acked-by: Tom Lendacky
>
> Shall I take this as a request (or permission, whatever :)) to merge it
> through the KVM tree?
Adding Herbert. Here&
On 4/15/21 1:03 AM, Tian Tao wrote:
> Since ccp_dev_suspend() and ccp_dev_resume() only return 0 which causes
> ret to equal 0 in sp_suspend and sp_resume, making the if condition
> impossible to use. it might be a more appropriate fix to have these be
> void functions and eliminate the if conditio
On 4/14/21 4:17 AM, Tian Tao wrote:
> ccp_dev_suspend and ccp_dev_resume return 0 on error, which causes
> ret to equal 0 in sp_suspend and sp_resume, making the if condition
> impossible to use.
Why do you think that is an error and why do you think it should return
-ENXIO? Since ccp_dev_suspend(
d structures on local stack
>
> arch/x86/kvm/svm/sev.c | 262 +--
> drivers/crypto/ccp/sev-dev.c | 197 +-
> drivers/crypto/ccp/sev-dev.h | 4 +-
> 3 files changed, 196 insertions(+), 267 deletions(-)
For the series:
Acked-by: Tom Lendacky
>
On 4/5/21 11:33 AM, Sean Christopherson wrote:
> On Mon, Apr 05, 2021, Tom Lendacky wrote:
>> On 4/2/21 6:36 PM, Sean Christopherson wrote:
>>> diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c
>>> index 6556d220713b..4c513318f16a 100644
>&
on-zero length and are not known to the kernel. This is not an
> explicit goal, but arguably the side effect is a good thing from the
> kernel's perspective.
>
> Cc: Brijesh Singh
> Cc: Borislav Petkov
> Cc: Tom Lendacky
> Signed-off-by: Sean Christopherson
>
On 3/9/21 2:11 AM, Rijo Thomas wrote:
> The first patch helps to improve the response time by reducing the
> polling time of the tee command status variable.
>
> Second patch is a bug fix to handle multi-threaded use-case.
> During testing, race condition was seen due to missing synchronisation
>
On 3/9/21 2:11 AM, Rijo Thomas wrote:
> Update the copyright year for PSP TEE driver files.
>
> Signed-off-by: Rijo Thomas
The copyright updates really should occur as part of the changes in the
other patches vs a separate patch.
Thanks,
Tom
> ---
> drivers/crypto/ccp/tee-dev.c | 2 +-
> driv
From: Tom Lendacky
If SEV has been disabled (e.g. through BIOS), the driver probe will still
issue SEV firmware commands. The SEV INIT firmware command will return an
error in this situation, but the error code is a general error code that
doesn't highlight the exact reason.
Add a chec
hen your BIOS supplier would incorporate it, so my only
suggestion is to not use the ccp and ccp-crypto modules for now.
Thanks,
Tom
Domen
-- Original Message --
From: "John Allen"
To: "Domen Stangar"
Cc: "Tom Lendacky" ;
"linux-crypto@vger.kernel.o
On 12/28/20 9:22 AM, John Allen wrote:
On Thu, Dec 17, 2020 at 07:42:52AM +, Domen Stangar wrote:
Hi,
I would like to report issue with ccp-crypto.
When I issue modprobe command, it would not continue, without SIGINT signal
(ctrl+c).
If module is compiled in kernel, boot doesn't finish.
Look
ESTATION_REPORT is that the later
> can be called while the guest is running and the measurement value is
> signed with PEK.
>
> Cc: James Bottomley
> Cc: Tom Lendacky
> Cc: David Rientjes
> Cc: Paolo Bonzini
> Cc: Sean Christopherson
> Cc: Borislav Petkov
> Cc: J
On 9/21/20 6:34 AM, Pavel Machek wrote:
> Fix resource leak in error handling.
Does it need a Fixes: tag?
Thanks,
Tom
>
> Signed-off-by: Pavel Machek (CIP)
>
> diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
> index bd270e66185e..40869ea1ed20 100644
> --- a/drivers/cr
On 7/21/20 11:30 AM, Vaibhav Gupta wrote:
> On Tue, Jul 21, 2020 at 10:19:33AM -0500, Tom Lendacky wrote:
>> On 7/21/20 7:31 AM, Vaibhav Gupta wrote:
>>> Drivers using legacy power management .suspen()/.resume() callbacks
>>> have to manage PCI states and device's
On 7/21/20 7:31 AM, Vaibhav Gupta wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
>
> Switch to generic power management framework using a
From: Tom Lendacky
Add John Allen as a new CCP driver maintainer. Additionally, break out
the driver SEV support and create a new maintainer entry, with Brijesh
Singh and Tom Lendacky as maintainers.
Cc: John Allen
Cc: Brijesh Singh
Signed-off-by: Tom Lendacky
---
Changes from v1:
- Change
From: Tom Lendacky
Add John Allen as a new CCP driver maintainer. Additionally, break out
the driver SEV support and create a new maintainer entry, with Brijesh
Singh and Tom Lendacky as maintainers.
Cc: John Allen
Cc: Brijesh Singh
Signed-off-by: Tom Lendacky
---
MAINTAINERS | 9
until the combined lengths of the entries seen is equal to the
DMA length of the current entry being processed in the DMA mapped
representation.
Fixes: 63b945091a070 ("crypto: ccp - CCP device driver and interface support")
Signed-off-by: John Allen
Acked-by: Tom Lendacky
n Ian King
Acked-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-ops.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index 422193690fd4..d270aa792888 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
ement SEV_PEK_CERT_IMPORT...")
Fixes: e799035609e1 ("crypto: ccp: Implement SEV_PEK_CSR ioctl...")
Fixes: 76a2b524a4b1 ("crypto: ccp - introduce SEV_GET_ID2 command")
Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command")
Signed-off-by: Herbert Xu
On 5/2/20 12:31 AM, Eric Biggers wrote:
From: Eric Biggers
Instead of manually allocating a 'struct shash_desc' on the stack and
calling crypto_shash_digest(), switch to using the new helper function
crypto_shash_tfm_digest() which does this for us.
Cc: Tom Lendacky
Signed-of
On 8/10/2018 9:11 AM, Tom Lendacky wrote:
> On 8/10/2018 2:03 AM, Thomas Backlund wrote:
>> Hi,
>>
>> this is tested on kernel 4.17.14
>>
>> hw:
>>
>> MSI X399 GAMING PRO CARBON AC (MS-7B09) bios 1.A0
>>
>> AMD Ryzen Threadripper 1950X
>&
On 8/10/2018 2:03 AM, Thomas Backlund wrote:
> Hi,
>
> this is tested on kernel 4.17.14
>
> hw:
>
> MSI X399 GAMING PRO CARBON AC (MS-7B09) bios 1.A0
>
> AMD Ryzen Threadripper 1950X
>
>
> Disabling psp in bios gets this in the logs:
Hmm, I'm not familiar with that BIOS option so I'm not exa
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
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
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
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
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
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
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
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 state
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 operations
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
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 each
* Author: Tom Lendacky
*
* 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_map[] = {
+static struct ccp_unit_size_map xts_unit_sizes
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
(CCP) AES XTS crypto API support
*
- * Copyright (C) 2013 Advanced Micro Devices, Inc.
+ * Copyright (C) 2013,2017 Advanced Micro Devices, Inc.
*
* Author: Tom Lendacky
*
@@ -37,46 +37,26 @@ struct ccp_unit_size_map {
u32 value;
};
-static struct ccp_unit_size_map
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
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
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: B
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 a/drivers/crypto/ccp/ccp-debugfs.c b/drivers/cr
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
---
drivers/crypto/ccp/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.
Sign
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 |1
drivers/crypt
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
---
drivers/crypto/ccp/ccp-dev-v5.c | 10 +
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
In order for memory pages to be properly mapped when SEV is active, we
need to use the PAGE_KERNEL protection attribute as
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
In order for memory pages to be properly mapped when SEV is active, we
need to
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
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 protection.
This will insure that
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
When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as
EFI related data, setup data) is encrypted and needs to be accessed as
such when mapped
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 to
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
* C
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
The use of ioremap will force the setup data to be mapped
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
The use of ioremap will force the setup data to be mapped decrypted even
though setup data is encrypted. Switch to using memremap which will be
able to perform the
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 insertions(+), 86 deletions
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
> ++
> drivers/crypto/ccp/ccp-crypto-main.
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 Lendacky
Maybe put your nam
On 10/13/2016 09:53 AM, Gary R Hook wrote:
> Take into account device implementation differences for
> RSA.
>
> Signed-off-by: Gary R Hook
> ---
> drivers/crypto/ccp/ccp-crypto-rsa.c | 14 +++--
> drivers/crypto/ccp/ccp-crypto.h |3 -
> drivers/crypto/ccp/ccp-dev.h|2 -
> d
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
> ++
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 +++--
> drivers/crypto/ccp/ccp-ops.c
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 +--
> drivers/crypto/ccp/ccp-dev.h|
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..."
>
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 red
On 09/22/2016 09:35 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 07:25:25PM -0400, Brijesh Singh wrote:
>> From: Tom Lendacky
>>
>> EFI data is encrypted when the kernel is run under SEV. Update the
>> page table references to be sure the EFI memory area
On 09/22/2016 09:59 AM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote:
>> The main difference between the SME and SEV encryption, from the point
>> of view of the kernel, is that real-mode always writes unencrypted in
>> SME and always writes encrypted in SE
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;
erface for SEV guests.
>>
>> Signed-off-by: Tom Lendacky
>> Signed-off-by: Brijesh Singh
>
> This driver doesn't seem to hook into the Crypto API at all, is
> there any reason why it should be in drivers/crypto?
Yes, this needs to be cleaned up. The PSP and the CC
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
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: # 3.14.x-
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-crypto-aes-xts.c | 17 -
1
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 submitted and accepted for this
Prevent information from leaking to userspace by doing a memset to 0 of
the export state structure before setting the structure values and copying
it. This prevents un-initialized padding areas from being copied into the
export area.
Cc: # 3.14.x-
Reported-by: Ben Hutchings
Signed-off-by: Tom
p_cmd_queue_thread(void *data);
>
> 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
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
---
MAINTAINERS |1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4a..8c42c07 100644
--- a/MAINTAINERS
+++ b
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
Acked-by: Tom Lendacky
> ---
> drivers/crypto/ccp/ccp-dev.c |6 +++---
> 1 file change
rsion structure (acting as a driver) with function
> pointers.
>
> Signed-off-by: Gary R Hook
Acked-by: Tom Lendacky
> ---
> drivers/crypto/ccp/Makefile |2
> drivers/crypto/ccp/ccp-dev-v3.c | 534
> +
> d
; and registers algorithms accordingly. A structure is added
> which manages the version-specific data.
>
> Signed-off-by: Gary R Hook
Acked-by: Tom Lendacky
> ---
> drivers/crypto/ccp/ccp-crypto-aes.c | 12 ++-
> drivers/crypto/ccp/ccp-crypto-sha.c |9 +++
On 03/01/2016 01:49 PM, Gary R Hook wrote:
> Enable management of >1 CCPs in a system. Each device will
> get a unique identifier, as well as uniquely named
> resources. Treat each CCP as an orthogonal unit and register
> resources individually.
>
> Signed-off-by: Gary R
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
Acked-by: Tom Lendacky
> ---
> drivers/crypto
.x-
Signed-off-by: Tom Lendacky
---
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/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
index d095452..3d9acc5 100644
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
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 req
use the local variable to set the request
context.
Cc: # 3.14.x-
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 26 +-
drivers/crypto/ccp/ccp-crypto-sha.c | 36 ++
2 files changed, 37 insertions(+), 25
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
>> needed.
>>
Since the exported information can be exposed to user-space, instead of
exporting the entire request context only export the minimum information
needed.
Cc: # 3.14.x-
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 16 +++-
drivers/crypto/ccp/ccp-crypto
On 01/25/2016 01:20 AM, Herbert Xu wrote:
> On Fri, Jan 22, 2016 at 11:22:48AM -0600, Tom Lendacky wrote:
>> On 01/12/2016 11:17 AM, Tom Lendacky wrote:
>>> Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
>>> added a check to preve
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
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
Tested-by: Tom Lendacky
Acked-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-ops.c | 39
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
Just a minor comment below.
Tested-by: Tom Lendacky
Acked-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-ops.c | 40
Replace the usage of BUG_ON with WARN_ON and return an error.
Signed-off-by: Tom Lendacky
---
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/crypto/ccp/ccp-ops.c
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
---
drivers/crypto/Kconfig |2 +-
drivers/crypto/ccp/Kconfig | 13 ++---
2 files changed, 7 insertions
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
---
drivers/crypto/ccp/ccp-pci.c |2
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
With the creation of the device_dma_is_coherent API the "use_acpi" field
is no longer needed, so remove it.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-platform.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-platform.c
b/drivers/cryp
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 C
ff-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-platform.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/ccp/ccp-platform.c
b/drivers/crypto/ccp/ccp-platform.c
index f2e6de3..bb241c3 100644
--- a/drivers/crypto/ccp/ccp-platform.c
+++ b/drivers/crypto/ccp/ccp-platform.c
@@ -
dma_map_sg() call to successfully map the
sg.
Signed-off-by: Tom Lendacky
---
include/linux/scatterlist.h |1 +
lib/scatterlist.c | 32
2 files changed, 33 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index
his by using the new sg_nents_for_len() 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
---
drivers/crypto/ccp/ccp-ops.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/dr
in errors/bugs being generated.
The following patches are included in this series:
- Introduce the sg_nents_for_len function
- Update the ccp driver to use the sg_nents_for_len function
This patch series is based on cryptodev-2.6.
---
Tom Lendacky (2):
scatterlist: introduce
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 al
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 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
On 05/27/2015 04:43 AM, Herbert Xu wrote:
Tom Lendacky 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 that based on
the data length
1 - 100 of 167 matches
Mail list logo
