Crypto Fixes for 4.11
Hi Linus: This push fixes the following issues: - vmalloc stack regression in CCM. - Build problem in CRC32 on ARM. - Memory leak in cavium. - Missing Kconfig dependencies in atmel and mediatek. - XTS Regression on some platforms (s390 and ppc). - Memory overrun in CCM test vector. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Ard Biesheuvel (3): crypto: ccm - move cbcmac input off the stack crypto: arm/crc32 - fix build error with outdated binutils crypto: arm/crc32 - add build time test for CRC instruction support Colin Ian King (1): crypto: cavium - fix leak on curr if curr->head fails to be allocated Geert Uytterhoeven (2): crypto: atmel - CRYPTO_DEV_ATMEL_TDES and CRYPTO_DEV_ATMEL_SHA should depend on HAS_DMA crypto: atmel - CRYPTO_DEV_MEDIATEK should depend on HAS_DMA George Cherian (1): crypto: cavium - Fix couple of static checker errors Herbert Xu (2): crypto: api - Add crypto_requires_off helper crypto: xts - Propagate NEED_FALLBACK bit Laura Abbott (1): crypto: testmgr - Pad aes_ccm_enc_tv_template vector Paulo Flabiano Smorigo (2): crypto: vmx - Use skcipher for cbc fallback crypto: vmx - Use skcipher for xts fallback arch/arm/crypto/Makefile | 12 ++- arch/arm/crypto/crc32-ce-core.S |2 +- crypto/ccm.c |5 +-- crypto/testmgr.h |2 +- crypto/xts.c | 14 drivers/crypto/Kconfig |3 ++ drivers/crypto/cavium/cpt/cptvf_main.c |5 ++- drivers/crypto/cavium/cpt/cptvf_reqmanager.c |4 +-- drivers/crypto/vmx/aes_cbc.c | 47 +- drivers/crypto/vmx/aes_xts.c | 32 +- include/crypto/algapi.h |7 +++- 11 files changed, 79 insertions(+), 54 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)
Hi Bjorn,
On 03/03/2017 02:33 PM, Bjorn Helgaas wrote:
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
This RFC series provides support for AMD's new Secure Encrypted Virtualization
(SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1].
What kernel version is this series based on?
This patch series is based off of the master branch of tip.
Commit a27cb9e1b2b4 ("Merge branch 'WIP.sched/core'")
Tom's RFC v4 patches (http://marc.info/?l=linux-mm&m=148725973013686&w=2)
Accidentally, I ended up rebasing SEV RFCv2 patches from updated SME v4
instead of original SME v4. So you may need to apply patch [1]
[1] http://marc.info/?l=linux-mm&m=148857523132253&w=2
Optionally, I have posted the full git tree here [2]
[2] https://github.com/codomania/tip/branches
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
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 proper mapping.
How should callers decide whether to use ioremap() or memremap()?
memremap() existed before SME and SEV, and this code is used even if
SME and SEV aren't supported, so the rationale for this change should
not need the decryption argument.
When SME or SEV is active an ioremap() will remove the encryption bit
from the pagetable entry when it is mapped. This allows MMIO, which
doesn't support SME/SEV, to be performed successfully. So my take is
that ioremap() should be used for MMIO and memremap() for pages in RAM.
Signed-off-by: Tom Lendacky
---
arch/x86/pci/common.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index a4fdfa7..0b06670 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -691,7 +691,7 @@ int pcibios_add_device(struct pci_dev *dev)
pa_data = boot_params.hdr.setup_data;
while (pa_data) {
- data = ioremap(pa_data, sizeof(*rom));
+ data = memremap(pa_data, sizeof(*rom), MEMREMAP_WB);
I can't quite connect the dots here. ioremap() on x86 would do
ioremap_nocache(). memremap(MEMREMAP_WB) would do arch_memremap_wb(),
which is ioremap_cache(). Is making a cacheable mapping the important
difference?
The memremap(MEMREMAP_WB) will actually check to see if it can perform
a __va(pa_data) in try_ram_remap() and then fallback to the
arch_memremap_wb(). So it's actually the __va() vs the ioremap_cache()
that is the difference.
Thanks,
Tom
if (!data)
return -ENOMEM;
@@ -710,7 +710,7 @@ int pcibios_add_device(struct pci_dev *dev)
}
}
pa_data = data->next;
- iounmap(data);
+ memunmap(data);
}
set_dma_domain_ops(dev);
set_dev_domain_options(dev);
Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature
Hi Boris,
On 03/03/2017 10:59 AM, Borislav Petkov wrote:
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
From: Tom Lendacky
Update the CPU features to include identifying and reporting on the
Secure Encrypted Virtualization (SEV) feature. SME is identified by
CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of
MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR). Only show the SEV feature
as available if reported by CPUID and enabled by BIOS.
Signed-off-by: Tom Lendacky
---
arch/x86/include/asm/cpufeatures.h |1 +
arch/x86/include/asm/msr-index.h |2 ++
arch/x86/kernel/cpu/amd.c | 22 ++
arch/x86/kernel/cpu/scattered.c|1 +
4 files changed, 22 insertions(+), 4 deletions(-)
So this patchset is not really ontop of Tom's patchset because this
patch doesn't apply. The reason is, Tom did the SME bit this way:
https://lkml.kernel.org/r/20170216154236.19244.7580.st...@tlendack-t1.amdoffice.net
but it should've been in scattered.c.
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index cabda87..c3f58d9 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -31,6 +31,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_CPB, CPUID_EDX, 9, 0x8007, 0 },
{ X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
{ X86_FEATURE_SME, CPUID_EAX, 0, 0x801f, 0 },
+ { X86_FEATURE_SEV, CPUID_EAX, 1, 0x801f, 0 },
{ 0, 0, 0, 0, 0 }
... and here it is in scattered.c, as it should be. So you've used an
older version of the patch, it seems.
Please sync with Tom to see whether he's reworked the v4 version of that
patch already. If yes, then you could send only the SME and SEV adding
patches as a reply to this message so that I can continue reviewing in
the meantime.
Just realized my error, I actually end up using Tom's recent updates to
v4 instead of original v4. Here is the diff. If you have Tom's v4
applied then apply this diff before applying SEV v2 version. Sorry about
that.
Optionally, you also pull the complete tree from github [1].
[1] https://github.com/codomania/tip/tree/sev-rfc-v2
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 91c40fa..b91e2495 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2153,8 +2153,8 @@
mem_encrypt=on: Activate SME
mem_encrypt=off:Do not activate SME
- Refer to the SME documentation for details on when
- memory encryption can be activated.
+ Refer to Documentation/x86/amd-memory-encryption.txt
+ for details on when memory encryption can be activated.
mem_sleep_default= [SUSPEND] Default system suspend mode:
s2idle - Suspend-To-Idle
diff --git a/Documentation/x86/amd-memory-encryption.txt
b/Documentation/x86/amd-memory-encryption.txt
index 0938e89..0b72ff2 100644
--- a/Documentation/x86/amd-memory-encryption.txt
+++ b/Documentation/x86/amd-memory-encryption.txt
@@ -7,9 +7,9 @@ DRAM. SME can therefore be used to protect the contents
of DRAM from physical
attacks on the system.
A page is encrypted when a page table entry has the encryption bit set
(see
-below how to determine the position of the bit). The encryption bit can be
-specified in the cr3 register, allowing the PGD table to be encrypted. Each
-successive level of page tables can also be encrypted.
+below on how to determine its position). The encryption bit can be
specified
+in the cr3 register, allowing the PGD table to be encrypted. Each
successive
+level of page tables can also be encrypted.
Support for SME can be determined through the CPUID instruction. The CPUID
function 0x801f reports information related to SME:
@@ -17,13 +17,14 @@ function 0x801f reports information related to SME:
0x801f[eax]:
Bit[0] indicates support for SME
0x801f[ebx]:
- Bit[5:0] pagetable bit number used to activate memory
- encryption
- Bit[11:6] reduction in physical address space, in bits, when
- memory encryption is enabled (this only affects system
- physical addresses, not guest physical addresses)
-
-If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to
+ Bits[5:0] pagetable bit number used to activate memory
+ encryption
+ Bits[11:6] reduction in physical address space, in bits, when
+ memory encryption is enabled (this only affects
+ system physical addresses, not guest p
Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)
On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> > This RFC series provides support for AMD's new Secure Encrypted
> > Virtualization
> > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4
> > [1].
>
> What kernel version is this series based on?
Yeah, see that mail in [1]:
https://lkml.kernel.org/r/20170216154158.19244.66630.st...@tlendack-t1.amdoffice.net
"This patch series is based off of the master branch of tip.
Commit a27cb9e1b2b4 ("Merge branch 'WIP.sched/core'")"
$ git describe a27cb9e1b2b4
v4.10-rc7-681-ga27cb9e1b2b4
So you need the SME pile first and then that SVE pile. But the first
patch needs refreshing as it is using a different base than the SME
pile. :-)
Tom, Brijesh, perhaps you guys could push a full tree somewhere - github
or so - for people to pull, in addition to the patchset on lkml.
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data
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 proper mapping.
How should callers decide whether to use ioremap() or memremap()?
memremap() existed before SME and SEV, and this code is used even if
SME and SEV aren't supported, so the rationale for this change should
not need the decryption argument.
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/pci/common.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index a4fdfa7..0b06670 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -691,7 +691,7 @@ int pcibios_add_device(struct pci_dev *dev)
>
> pa_data = boot_params.hdr.setup_data;
> while (pa_data) {
> - data = ioremap(pa_data, sizeof(*rom));
> + data = memremap(pa_data, sizeof(*rom), MEMREMAP_WB);
I can't quite connect the dots here. ioremap() on x86 would do
ioremap_nocache(). memremap(MEMREMAP_WB) would do arch_memremap_wb(),
which is ioremap_cache(). Is making a cacheable mapping the important
difference?
> if (!data)
> return -ENOMEM;
>
> @@ -710,7 +710,7 @@ int pcibios_add_device(struct pci_dev *dev)
> }
> }
> pa_data = data->next;
> - iounmap(data);
> + memunmap(data);
> }
> set_dma_domain_ops(dev);
> set_dev_domain_options(dev);
>
Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote: > This RFC series provides support for AMD's new Secure Encrypted Virtualization > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 > [1]. What kernel version is this series based on?
[RFC 1/7] soc/qman: export volatile dequeue related structs
Since qman_volatile_dequeue() is already exported, move the related
structures into the public header too.
Signed-off-by: Horia Geantă
---
drivers/soc/fsl/qbman/qman_priv.h | 36
include/soc/fsl/qman.h| 36
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman_priv.h
b/drivers/soc/fsl/qbman/qman_priv.h
index 53685b59718e..64781eff6974 100644
--- a/drivers/soc/fsl/qbman/qman_priv.h
+++ b/drivers/soc/fsl/qbman/qman_priv.h
@@ -271,42 +271,6 @@ const struct qm_portal_config
*qman_destroy_affine_portal(void);
*/
int qman_query_fq(struct qman_fq *fq, struct qm_fqd *fqd);
-/*
- * For qman_volatile_dequeue(); Choose one PRECEDENCE. EXACT is optional. Use
- * NUMFRAMES(n) (6-bit) or NUMFRAMES_TILLEMPTY to fill in the frame-count. Use
- * FQID(n) to fill in the frame queue ID.
- */
-#define QM_VDQCR_PRECEDENCE_VDQCR 0x0
-#define QM_VDQCR_PRECEDENCE_SDQCR 0x8000
-#define QM_VDQCR_EXACT 0x4000
-#define QM_VDQCR_NUMFRAMES_MASK0x3f00
-#define QM_VDQCR_NUMFRAMES_SET(n) (((n) & 0x3f) << 24)
-#define QM_VDQCR_NUMFRAMES_GET(n) (((n) >> 24) & 0x3f)
-#define QM_VDQCR_NUMFRAMES_TILLEMPTY QM_VDQCR_NUMFRAMES_SET(0)
-
-#define QMAN_VOLATILE_FLAG_WAIT 0x0001 /* wait if VDQCR is in
use */
-#define QMAN_VOLATILE_FLAG_WAIT_INT 0x0002 /* if wait, interruptible? */
-#define QMAN_VOLATILE_FLAG_FINISH0x0004 /* wait till VDQCR completes */
-
-/*
- * qman_volatile_dequeue - Issue a volatile dequeue command
- * @fq: the frame queue object to dequeue from
- * @flags: a bit-mask of QMAN_VOLATILE_FLAG_*** options
- * @vdqcr: bit mask of QM_VDQCR_*** options, as per qm_dqrr_vdqcr_set()
- *
- * Attempts to lock access to the portal's VDQCR volatile dequeue
functionality.
- * The function will block and sleep if QMAN_VOLATILE_FLAG_WAIT is specified
and
- * the VDQCR is already in use, otherwise returns non-zero for failure. If
- * QMAN_VOLATILE_FLAG_FINISH is specified, the function will only return once
- * the VDQCR command has finished executing (ie. once the callback for the last
- * DQRR entry resulting from the VDQCR command has been called). If not using
- * the FINISH flag, completion can be determined either by detecting the
- * presence of the QM_DQRR_STAT_UNSCHEDULED and QM_DQRR_STAT_DQCR_EXPIRED bits
- * in the "stat" parameter passed to the FQ's dequeue callback, or by waiting
- * for the QMAN_FQ_STATE_VDQCR bit to disappear.
- */
-int qman_volatile_dequeue(struct qman_fq *fq, u32 flags, u32 vdqcr);
-
int qman_alloc_fq_table(u32 num_fqids);
/* QMan s/w corenet portal, low-level i/face */
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 3d4df74a96de..4de1ffcc8982 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -791,6 +791,23 @@ struct qman_cgr {
#define QMAN_INITFQ_FLAG_SCHED 0x0001 /* schedule rather than park */
#define QMAN_INITFQ_FLAG_LOCAL 0x0004 /* set dest portal */
+/*
+ * For qman_volatile_dequeue(); Choose one PRECEDENCE. EXACT is optional. Use
+ * NUMFRAMES(n) (6-bit) or NUMFRAMES_TILLEMPTY to fill in the frame-count. Use
+ * FQID(n) to fill in the frame queue ID.
+ */
+#define QM_VDQCR_PRECEDENCE_VDQCR 0x0
+#define QM_VDQCR_PRECEDENCE_SDQCR 0x8000
+#define QM_VDQCR_EXACT 0x4000
+#define QM_VDQCR_NUMFRAMES_MASK0x3f00
+#define QM_VDQCR_NUMFRAMES_SET(n) (((n) & 0x3f) << 24)
+#define QM_VDQCR_NUMFRAMES_GET(n) (((n) >> 24) & 0x3f)
+#define QM_VDQCR_NUMFRAMES_TILLEMPTY QM_VDQCR_NUMFRAMES_SET(0)
+
+#define QMAN_VOLATILE_FLAG_WAIT 0x0001 /* wait if VDQCR is in
use */
+#define QMAN_VOLATILE_FLAG_WAIT_INT 0x0002 /* if wait, interruptible? */
+#define QMAN_VOLATILE_FLAG_FINISH0x0004 /* wait till VDQCR completes */
+
/* Portal Management */
/**
* qman_p_irqsource_add - add processing sources to be interrupt-driven
@@ -963,6 +980,25 @@ int qman_retire_fq(struct qman_fq *fq, u32 *flags);
*/
int qman_oos_fq(struct qman_fq *fq);
+/*
+ * qman_volatile_dequeue - Issue a volatile dequeue command
+ * @fq: the frame queue object to dequeue from
+ * @flags: a bit-mask of QMAN_VOLATILE_FLAG_*** options
+ * @vdqcr: bit mask of QM_VDQCR_*** options, as per qm_dqrr_vdqcr_set()
+ *
+ * Attempts to lock access to the portal's VDQCR volatile dequeue
functionality.
+ * The function will block and sleep if QMAN_VOLATILE_FLAG_WAIT is specified
and
+ * the VDQCR is already in use, otherwise returns non-zero for failure. If
+ * QMAN_VOLATILE_FLAG_FINISH is specified, the function will only return once
+ * the VDQCR command has finished executing (ie. once the callback for the last
+ * DQRR entry resulting from the VDQCR command has been called). If not using
+ * the FINISH flag, completion can be determined either by detecting the
+ * presence of the
Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Update the CPU features to include identifying and reporting on the
> Secure Encrypted Virtualization (SEV) feature. SME is identified by
> CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of
> MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR). Only show the SEV feature
> as available if reported by CPUID and enabled by BIOS.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cpufeatures.h |1 +
> arch/x86/include/asm/msr-index.h |2 ++
> arch/x86/kernel/cpu/amd.c | 22 ++
> arch/x86/kernel/cpu/scattered.c|1 +
> 4 files changed, 22 insertions(+), 4 deletions(-)
So this patchset is not really ontop of Tom's patchset because this
patch doesn't apply. The reason is, Tom did the SME bit this way:
https://lkml.kernel.org/r/20170216154236.19244.7580.st...@tlendack-t1.amdoffice.net
but it should've been in scattered.c.
> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index cabda87..c3f58d9 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -31,6 +31,7 @@ static const struct cpuid_bit cpuid_bits[] = {
> { X86_FEATURE_CPB, CPUID_EDX, 9, 0x8007, 0 },
> { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> { X86_FEATURE_SME, CPUID_EAX, 0, 0x801f, 0 },
> + { X86_FEATURE_SEV, CPUID_EAX, 1, 0x801f, 0 },
> { 0, 0, 0, 0, 0 }
... and here it is in scattered.c, as it should be. So you've used an
older version of the patch, it seems.
Please sync with Tom to see whether he's reworked the v4 version of that
patch already. If yes, then you could send only the SME and SEV adding
patches as a reply to this message so that I can continue reviewing in
the meantime.
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
[RFC 4/7] soc/qman: add helper functions needed by caam/qi driver
Add helper functions, macros, #defines for accessing / enabling
qman functionality from caam/qi driver, such that this driver
is not aware of the need for data conversion to big endian.
qman is updated to use these helpers internally.
Signed-off-by: Horia Geantă
---
drivers/soc/fsl/qbman/qman.c| 16 +--
drivers/soc/fsl/qbman/qman_test_stash.c | 5 ++--
include/soc/fsl/qman.h | 47 +
3 files changed, 56 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 3d891db57ee6..7668ff53cd90 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1764,16 +1764,15 @@ int qman_init_fq(struct qman_fq *fq, u32 flags, struct
qm_mcc_initfq *opts)
if (fq_isclear(fq, QMAN_FQ_FLAG_TO_DCPORTAL)) {
dma_addr_t phys_fq;
- mcc->initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_CONTEXTB);
- mcc->initfq.fqd.context_b = cpu_to_be32(fq_to_tag(fq));
+ qm_initfq_setbits(&mcc->initfq, QM_INITFQ_WE_CONTEXTB);
+ qm_fqd_set_contextb(&mcc->initfq.fqd, fq_to_tag(fq));
/*
* and the physical address - NB, if the user wasn't trying to
* set CONTEXTA, clear the stashing settings.
*/
if (!(be16_to_cpu(mcc->initfq.we_mask) &
QM_INITFQ_WE_CONTEXTA)) {
- mcc->initfq.we_mask |=
- cpu_to_be16(QM_INITFQ_WE_CONTEXTA);
+ qm_initfq_setbits(&mcc->initfq, QM_INITFQ_WE_CONTEXTA);
memset(&mcc->initfq.fqd.context_a, 0,
sizeof(mcc->initfq.fqd.context_a));
} else {
@@ -1795,8 +1794,7 @@ int qman_init_fq(struct qman_fq *fq, u32 flags, struct
qm_mcc_initfq *opts)
if (!(be16_to_cpu(mcc->initfq.we_mask) &
QM_INITFQ_WE_DESTWQ)) {
- mcc->initfq.we_mask |=
- cpu_to_be16(QM_INITFQ_WE_DESTWQ);
+ qm_initfq_setbits(&mcc->initfq, QM_INITFQ_WE_DESTWQ);
wq = 4;
}
qm_fqd_set_destwq(&mcc->initfq.fqd, p->config->channel, wq);
@@ -1816,7 +1814,7 @@ int qman_init_fq(struct qman_fq *fq, u32 flags, struct
qm_mcc_initfq *opts)
}
if (opts) {
if (be16_to_cpu(opts->we_mask) & QM_INITFQ_WE_FQCTRL) {
- if (be16_to_cpu(opts->fqd.fq_ctrl) & QM_FQCTRL_CGE)
+ if (qm_fqd_isset_fqctrl(&opts->fqd, QM_FQCTRL_CGE))
fq_set(fq, QMAN_FQ_STATE_CGR_EN);
else
fq_clear(fq, QMAN_FQ_STATE_CGR_EN);
@@ -2321,7 +2319,7 @@ int qman_create_cgr(struct qman_cgr *cgr, u32 flags,
qm_cgr_cscn_targ_set(&local_opts.cgr, PORTAL_IDX(p),
be32_to_cpu(cgr_state.cgr.cscn_targ));
- local_opts.we_mask |= cpu_to_be16(QM_CGR_WE_CSCN_TARG);
+ qm_initcgr_setbits(&local_opts, QM_CGR_WE_CSCN_TARG);
/* send init if flags indicate so */
if (flags & QMAN_CGR_FLAG_USE_INIT)
@@ -2840,7 +2838,7 @@ static int cgr_cleanup(u32 cgrid)
err = qman_query_fq(&fq, &fqd);
if (WARN_ON(err))
return err;
- if (be16_to_cpu(fqd.fq_ctrl) & QM_FQCTRL_CGE &&
+ if (qm_fqd_isset_fqctrl(&fqd, QM_FQCTRL_CGE) &&
fqd.cgid == cgrid) {
pr_err("CRGID 0x%x is being used by FQID 0x%x,
CGR will be leaked\n",
cgrid, fq.fqid);
diff --git a/drivers/soc/fsl/qbman/qman_test_stash.c
b/drivers/soc/fsl/qbman/qman_test_stash.c
index e87b65403b67..d2bf453092d7 100644
--- a/drivers/soc/fsl/qbman/qman_test_stash.c
+++ b/drivers/soc/fsl/qbman/qman_test_stash.c
@@ -406,9 +406,8 @@ static int init_handler(void *h)
goto failed;
}
memset(&opts, 0, sizeof(opts));
- opts.we_mask = cpu_to_be16(QM_INITFQ_WE_FQCTRL |
- QM_INITFQ_WE_CONTEXTA);
- opts.fqd.fq_ctrl = cpu_to_be16(QM_FQCTRL_CTXASTASHING);
+ qm_initfq_setbits(&opts, QM_INITFQ_WE_FQCTRL | QM_INITFQ_WE_CONTEXTA);
+ qm_fqd_set_fqctrl(&opts.fqd, QM_FQCTRL_CTXASTASHING);
qm_fqd_set_stashing(&opts.fqd, 0, STASH_DATA_CL, STASH_CTX_CL);
err = qman_init_fq(&handler->rx, QMAN_INITFQ_FLAG_SCHED |
QMAN_INITFQ_FLAG_LOCAL, &opts);
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 0252c32f7421..fc133c658385 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -168,6 +168,12 @@ static inline void qm_fd_set_param(struct qm
[RFC 3/7] soc/qman: export non-programmable FQD fields query
Export qman_query_fq_np() function and related structures.
This will be needed in the caam/qi driver, where "queue empty"
condition will be decided based on the frm_cnt.
Signed-off-by: Horia Geantă
---
drivers/soc/fsl/qbman/qman.c | 4 +--
drivers/soc/fsl/qbman/qman_priv.h | 61 ---
include/soc/fsl/qman.h| 68 +++
3 files changed, 70 insertions(+), 63 deletions(-)
diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 6f509f68085e..3d891db57ee6 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -2019,8 +2019,7 @@ int qman_query_fq(struct qman_fq *fq, struct qm_fqd *fqd)
return ret;
}
-static int qman_query_fq_np(struct qman_fq *fq,
- struct qm_mcr_queryfq_np *np)
+int qman_query_fq_np(struct qman_fq *fq, struct qm_mcr_queryfq_np *np)
{
union qm_mc_command *mcc;
union qm_mc_result *mcr;
@@ -2046,6 +2045,7 @@ static int qman_query_fq_np(struct qman_fq *fq,
put_affine_portal();
return ret;
}
+EXPORT_SYMBOL(qman_query_fq_np);
static int qman_query_cgr(struct qman_cgr *cgr,
struct qm_mcr_querycgr *cgrd)
diff --git a/drivers/soc/fsl/qbman/qman_priv.h
b/drivers/soc/fsl/qbman/qman_priv.h
index 64781eff6974..22725bdc6f15 100644
--- a/drivers/soc/fsl/qbman/qman_priv.h
+++ b/drivers/soc/fsl/qbman/qman_priv.h
@@ -89,67 +89,6 @@ static inline u64 qm_mcr_querycgr_a_get64(const struct
qm_mcr_querycgr *q)
return ((u64)q->a_bcnt_hi << 32) | be32_to_cpu(q->a_bcnt_lo);
}
-/* "Query FQ Non-Programmable Fields" */
-
-struct qm_mcr_queryfq_np {
- u8 verb;
- u8 result;
- u8 __reserved1;
- u8 state; /* QM_MCR_NP_STATE_*** */
- u32 fqd_link; /* 24-bit, _res2[24-31] */
- u16 odp_seq;/* 14-bit, _res3[14-15] */
- u16 orp_nesn; /* 14-bit, _res4[14-15] */
- u16 orp_ea_hseq;/* 15-bit, _res5[15] */
- u16 orp_ea_tseq;/* 15-bit, _res6[15] */
- u32 orp_ea_hptr;/* 24-bit, _res7[24-31] */
- u32 orp_ea_tptr;/* 24-bit, _res8[24-31] */
- u32 pfdr_hptr; /* 24-bit, _res9[24-31] */
- u32 pfdr_tptr; /* 24-bit, _res10[24-31] */
- u8 __reserved2[5];
- u8 is; /* 1-bit, _res12[1-7] */
- u16 ics_surp;
- u32 byte_cnt;
- u32 frm_cnt;/* 24-bit, _res13[24-31] */
- u32 __reserved3;
- u16 ra1_sfdr; /* QM_MCR_NP_RA1_*** */
- u16 ra2_sfdr; /* QM_MCR_NP_RA2_*** */
- u16 __reserved4;
- u16 od1_sfdr; /* QM_MCR_NP_OD1_*** */
- u16 od2_sfdr; /* QM_MCR_NP_OD2_*** */
- u16 od3_sfdr; /* QM_MCR_NP_OD3_*** */
-} __packed;
-
-#define QM_MCR_NP_STATE_FE 0x10
-#define QM_MCR_NP_STATE_R 0x08
-#define QM_MCR_NP_STATE_MASK 0x07/* Reads FQD::STATE; */
-#define QM_MCR_NP_STATE_OOS0x00
-#define QM_MCR_NP_STATE_RETIRED0x01
-#define QM_MCR_NP_STATE_TEN_SCHED 0x02
-#define QM_MCR_NP_STATE_TRU_SCHED 0x03
-#define QM_MCR_NP_STATE_PARKED 0x04
-#define QM_MCR_NP_STATE_ACTIVE 0x05
-#define QM_MCR_NP_PTR_MASK 0x07ff /* for RA[12] & OD[123] */
-#define QM_MCR_NP_RA1_NRA(v) (((v) >> 14) & 0x3) /* FQD::NRA */
-#define QM_MCR_NP_RA2_IT(v)(((v) >> 14) & 0x1) /* FQD::IT */
-#define QM_MCR_NP_OD1_NOD(v) (((v) >> 14) & 0x3) /* FQD::NOD */
-#define QM_MCR_NP_OD3_NPC(v) (((v) >> 14) & 0x3) /* FQD::NPC */
-
-enum qm_mcr_queryfq_np_masks {
- qm_mcr_fqd_link_mask = BIT(24)-1,
- qm_mcr_odp_seq_mask = BIT(14)-1,
- qm_mcr_orp_nesn_mask = BIT(14)-1,
- qm_mcr_orp_ea_hseq_mask = BIT(15)-1,
- qm_mcr_orp_ea_tseq_mask = BIT(15)-1,
- qm_mcr_orp_ea_hptr_mask = BIT(24)-1,
- qm_mcr_orp_ea_tptr_mask = BIT(24)-1,
- qm_mcr_pfdr_hptr_mask = BIT(24)-1,
- qm_mcr_pfdr_tptr_mask = BIT(24)-1,
- qm_mcr_is_mask = BIT(1)-1,
- qm_mcr_frm_cnt_mask = BIT(24)-1,
-};
-#define qm_mcr_np_get(np, field) \
- ((np)->field & (qm_mcr_##field##_mask))
-
/* Congestion Groups */
/*
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 10b549783ec5..0252c32f7421 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -811,6 +811,67 @@ struct qman_cgr {
#define QMAN_VOLATILE_FLAG_WAIT_INT 0x0002 /* if wait, interruptible? */
#define QMAN_VOLATILE_FLAG_FINISH0x0004 /* wait till VDQCR completes */
+/* "Query FQ Non-Programmable Fields" */
+struct qm_mcr_queryfq_np {
+ u8 verb;
+ u8 result;
+ u8 __reserved1;
+ u8 state; /* QM_MCR_NP_STATE_*** */
+ u32 fqd_link; /* 24-bit, _res2[24-31] */
+ u16 odp_seq;/* 14-bit, _res3[14-15] */
+
[RFC 2/7] soc/qman: add dedicated channel ID for CAAM
Add and export the ID of the channel serviced by the
CAAM (Cryptographic Acceleration and Assurance Module) DCP.
Signed-off-by: Horia Geantă
---
drivers/soc/fsl/qbman/qman_ccsr.c | 6 +-
include/soc/fsl/qman.h| 3 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c
b/drivers/soc/fsl/qbman/qman_ccsr.c
index f4e6e70de259..90bc40c48675 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -34,6 +34,8 @@ u16 qman_ip_rev;
EXPORT_SYMBOL(qman_ip_rev);
u16 qm_channel_pool1 = QMAN_CHANNEL_POOL1;
EXPORT_SYMBOL(qm_channel_pool1);
+u16 qm_channel_caam = QMAN_CHANNEL_CAAM;
+EXPORT_SYMBOL(qm_channel_caam);
/* Register offsets */
#define REG_QCSP_LIO_CFG(n)(0x + ((n) * 0x10))
@@ -720,8 +722,10 @@ static int fsl_qman_probe(struct platform_device *pdev)
return -ENODEV;
}
- if ((qman_ip_rev & 0xff00) >= QMAN_REV30)
+ if ((qman_ip_rev & 0xff00) >= QMAN_REV30) {
qm_channel_pool1 = QMAN_CHANNEL_POOL1_REV3;
+ qm_channel_caam = QMAN_CHANNEL_CAAM_REV3;
+ }
ret = zero_priv_mem(dev, node, fqd_a, fqd_sz);
WARN_ON(ret);
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 4de1ffcc8982..10b549783ec5 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -36,8 +36,11 @@
/* Hardware constants */
#define QM_CHANNEL_SWPORTAL0 0
#define QMAN_CHANNEL_POOL1 0x21
+#define QMAN_CHANNEL_CAAM 0x80
#define QMAN_CHANNEL_POOL1_REV3 0x401
+#define QMAN_CHANNEL_CAAM_REV3 0x840
extern u16 qm_channel_pool1;
+extern u16 qm_channel_caam;
/* Portal processing (interrupt) sources */
#define QM_PIRQ_CSCI 0x0010 /* Congestion State Change */
--
2.4.4
[RFC 0/7] crypto: caam - add Queue Interface (QI) support
The patchset adds support for CAAM Queue Interface (QI), the additional interface (besides job ring) available for submitting jobs to the engine on platforms having DPAA (Datapath Acceleration Architecture). Patches 1-4 are QMan dependencies. I would prefer to take them through the crypto tree, but I am open to suggestions. Patch 5 adds a missing double inclusion guard in desc_constr.h. Patch 6 adds the caam/qi job submission backend. Patch 7 adds algorithms (ablkcipher and authenc) that run on top of caam/qi. For now, their priority is set lower than caam/jr. Thanks, Horia Horia Geantă (7): soc/qman: export volatile dequeue related structs soc/qman: add dedicated channel ID for CAAM soc/qman: export non-programmable FQD fields query soc/qman: add helper functions needed by caam/qi driver crypto: caam - avoid double inclusion in desc_constr.h crypto: caam - add Queue Interface (QI) backend support crypto: caam/qi - add ablkcipher and authenc algorithms drivers/crypto/caam/Kconfig | 20 +- drivers/crypto/caam/Makefile|5 + drivers/crypto/caam/caamalg.c |9 +- drivers/crypto/caam/caamalg_desc.c | 77 +- drivers/crypto/caam/caamalg_desc.h | 15 +- drivers/crypto/caam/caamalg_qi.c| 2387 +++ drivers/crypto/caam/ctrl.c | 58 +- drivers/crypto/caam/desc_constr.h |5 + drivers/crypto/caam/intern.h| 24 + drivers/crypto/caam/qi.c| 805 +++ drivers/crypto/caam/qi.h| 201 +++ drivers/crypto/caam/sg_sw_qm.h | 107 ++ drivers/soc/fsl/qbman/qman.c| 20 +- drivers/soc/fsl/qbman/qman_ccsr.c |6 +- drivers/soc/fsl/qbman/qman_priv.h | 97 -- drivers/soc/fsl/qbman/qman_test_stash.c |5 +- include/soc/fsl/qman.h | 154 ++ 17 files changed, 3839 insertions(+), 156 deletions(-) create mode 100644 drivers/crypto/caam/caamalg_qi.c create mode 100644 drivers/crypto/caam/qi.c create mode 100644 drivers/crypto/caam/qi.h create mode 100644 drivers/crypto/caam/sg_sw_qm.h -- 2.4.4
[RFC 5/7] crypto: caam - avoid double inclusion in desc_constr.h
Signed-off-by: Horia Geantă --- drivers/crypto/caam/desc_constr.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/crypto/caam/desc_constr.h b/drivers/crypto/caam/desc_constr.h index b9c8d98ef826..d8e83ca104e0 100644 --- a/drivers/crypto/caam/desc_constr.h +++ b/drivers/crypto/caam/desc_constr.h @@ -4,6 +4,9 @@ * Copyright 2008-2012 Freescale Semiconductor, Inc. */ +#ifndef DESC_CONSTR_H +#define DESC_CONSTR_H + #include "desc.h" #include "regs.h" @@ -491,3 +494,5 @@ static inline int desc_inline_query(unsigned int sd_base_len, return (rem_bytes >= 0) ? 0 : -1; } + +#endif /* DESC_CONSTR_H */ -- 2.4.4
[RFC 7/7] crypto: caam/qi - add ablkcipher and authenc algorithms
Add support to submit ablkcipher and authenc algorithms
via the QI backend:
-ablkcipher:
cbc({aes,des,des3_ede})
ctr(aes), rfc3686(ctr(aes))
xts(aes)
-authenc:
authenc(hmac(md5),cbc({aes,des,des3_ede}))
authenc(hmac(sha*),cbc({aes,des,des3_ede}))
caam/qi being a new driver, let's wait some time to settle down without
interfering with existing caam/jr driver.
Accordingly, for now all caam/qi algorithms (caamalg_qi module) are
marked to be of lower priority than caam/jr ones (caamalg module).
Signed-off-by: Vakul Garg
Signed-off-by: Alex Porosanu
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Kconfig| 20 +-
drivers/crypto/caam/Makefile |1 +
drivers/crypto/caam/caamalg.c |9 +-
drivers/crypto/caam/caamalg_desc.c | 77 +-
drivers/crypto/caam/caamalg_desc.h | 15 +-
drivers/crypto/caam/caamalg_qi.c | 2387
drivers/crypto/caam/sg_sw_qm.h | 107 ++
7 files changed, 2600 insertions(+), 16 deletions(-)
create mode 100644 drivers/crypto/caam/caamalg_qi.c
create mode 100644 drivers/crypto/caam/sg_sw_qm.h
diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index bc0d3569f8d9..e36aeacd7635 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -87,6 +87,23 @@ config CRYPTO_DEV_FSL_CAAM_CRYPTO_API
To compile this as a module, choose M here: the module
will be called caamalg.
+config CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI
+ tristate "Queue Interface as Crypto API backend"
+ depends on CRYPTO_DEV_FSL_CAAM_JR && FSL_DPAA && NET
+ default y
+ select CRYPTO_AUTHENC
+ select CRYPTO_BLKCIPHER
+ help
+ Selecting this will use CAAM Queue Interface (QI) for sending
+ & receiving crypto jobs to/from CAAM. This gives better performance
+ than job ring interface when the number of cores are more than the
+ number of job rings assigned to the kernel. The number of portals
+ assigned to the kernel should also be more than the number of
+ job rings.
+
+ To compile this as a module, choose M here: the module
+ will be called caamalg_qi.
+
config CRYPTO_DEV_FSL_CAAM_AHASH_API
tristate "Register hash algorithm implementations with Crypto API"
depends on CRYPTO_DEV_FSL_CAAM_JR
@@ -136,4 +153,5 @@ config CRYPTO_DEV_FSL_CAAM_DEBUG
information in the CAAM driver.
config CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC
- def_tristate CRYPTO_DEV_FSL_CAAM_CRYPTO_API
+ def_tristate (CRYPTO_DEV_FSL_CAAM_CRYPTO_API || \
+ CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI)
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 2e60e45c2bf1..9e2e98856b9b 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -8,6 +8,7 @@ endif
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI) += caamalg_qi.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC) += caamalg_desc.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 9bc80eb06934..398807d1b77e 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -266,8 +266,9 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
/* aead_encrypt shared descriptor */
desc = ctx->sh_desc_enc;
- cnstr_shdsc_aead_encap(desc, &ctx->cdata, &ctx->adata, ctx->authsize,
- is_rfc3686, nonce, ctx1_iv_off);
+ cnstr_shdsc_aead_encap(desc, &ctx->cdata, &ctx->adata, ivsize,
+ ctx->authsize, is_rfc3686, nonce, ctx1_iv_off,
+ false);
dma_sync_single_for_device(jrdev, ctx->sh_desc_enc_dma,
desc_bytes(desc), DMA_TO_DEVICE);
@@ -299,7 +300,7 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
desc = ctx->sh_desc_dec;
cnstr_shdsc_aead_decap(desc, &ctx->cdata, &ctx->adata, ivsize,
ctx->authsize, alg->caam.geniv, is_rfc3686,
- nonce, ctx1_iv_off);
+ nonce, ctx1_iv_off, false);
dma_sync_single_for_device(jrdev, ctx->sh_desc_dec_dma,
desc_bytes(desc), DMA_TO_DEVICE);
@@ -333,7 +334,7 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
desc = ctx->sh_desc_enc;
cnstr_shdsc_aead_givencap(desc, &ctx->cdata, &ctx->adata, ivsize,
ctx->authsize, is_rfc3686, nonce,
- ctx1_iv_off);
+ ctx1_iv_off, false);
dma_sync_single_for_device(jrdev, ctx->sh_desc_enc_dma,
[RFC 6/7] crypto: caam - add Queue Interface (QI) backend support
CAAM engine supports two interfaces for crypto job submission:
-job ring interface - already existing caam/jr driver
-Queue Interface (QI) - caam/qi driver added in current patch
QI is present in CAAM engines found on DPAA platforms.
QI gets its I/O (frame descriptors) from QMan (Queue Manager) queues.
This patch adds a platform device for accessing CAAM's queue interface.
The requests are submitted to CAAM using one frame queue per
cryptographic context. Each crypto context has one shared descriptor.
This shared descriptor is attached to frame queue associated with
corresponding driver context using context_a.
The driver hides the mechanics of FQ creation, initialisation from its
applications. Each cryptographic context needs to be associated with
driver context which houses the FQ to be used to transport the job to
CAAM. The driver provides API for:
(a) Context creation
(b) Job submission
(c) Context deletion
(d) Congestion indication - whether path to/from CAAM is congested
The driver supports affining its context to a particular CPU.
This means that any responses from CAAM for the context in question
would arrive at the given CPU. This helps in implementing one CPU
per packet round trip in IPsec application.
The driver processes CAAM responses under NAPI contexts.
NAPI contexts are instantiated only on cores with affined portals since
only cores having their own portal can receive responses from DQRR.
The responses from CAAM for all cryptographic contexts ride on a fixed
set of FQs. We use one response FQ per portal owning core. The response
FQ is configured in each core's and thus portal's dedicated channel.
This gives the flexibility to direct CAAM's responses for a crypto
context on a given core.
Signed-off-by: Vakul Garg
Signed-off-by: Alex Porosanu
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Makefile | 4 +
drivers/crypto/caam/ctrl.c | 58 ++--
drivers/crypto/caam/intern.h | 24 ++
drivers/crypto/caam/qi.c | 805 +++
drivers/crypto/caam/qi.h | 201 +++
5 files changed, 1064 insertions(+), 28 deletions(-)
create mode 100644 drivers/crypto/caam/qi.c
create mode 100644 drivers/crypto/caam/qi.h
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 6554742f357e..2e60e45c2bf1 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -16,3 +16,7 @@ obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caam_pkc.o
caam-objs := ctrl.o
caam_jr-objs := jr.o key_gen.o error.o
caam_pkc-y := caampkc.o pkc_desc.o
+ifneq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI),)
+ ccflags-y += -DCONFIG_CAAM_QI
+ caam-objs += qi.o
+endif
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 579f8263c479..9f91de315c30 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -18,6 +18,10 @@
bool caam_little_end;
EXPORT_SYMBOL(caam_little_end);
+#ifdef CONFIG_CAAM_QI
+#include "qi.h"
+#endif
+
/*
* i.MX targets tend to have clock control subsystems that can
* enable/disable clocking to our device.
@@ -311,6 +315,11 @@ static int caam_remove(struct platform_device *pdev)
for (ring = 0; ring < ctrlpriv->total_jobrs; ring++)
of_device_unregister(ctrlpriv->jrpdev[ring]);
+#ifdef CONFIG_CAAM_QI
+ if (ctrlpriv->qidev)
+ caam_qi_shutdown(ctrlpriv->qidev);
+#endif
+
/* De-initialize RNG state handles initialized by this driver. */
if (ctrlpriv->rng4_sh_init)
deinstantiate_rng(ctrldev, ctrlpriv->rng4_sh_init);
@@ -401,23 +410,6 @@ int caam_get_era(void)
}
EXPORT_SYMBOL(caam_get_era);
-#ifdef CONFIG_DEBUG_FS
-static int caam_debugfs_u64_get(void *data, u64 *val)
-{
- *val = caam64_to_cpu(*(u64 *)data);
- return 0;
-}
-
-static int caam_debugfs_u32_get(void *data, u64 *val)
-{
- *val = caam32_to_cpu(*(u32 *)data);
- return 0;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(caam_fops_u32_ro, caam_debugfs_u32_get, NULL,
"%llu\n");
-DEFINE_SIMPLE_ATTRIBUTE(caam_fops_u64_ro, caam_debugfs_u64_get, NULL,
"%llu\n");
-#endif
-
/* Probe routine for CAAM top (controller) level */
static int caam_probe(struct platform_device *pdev)
{
@@ -615,6 +607,17 @@ static int caam_probe(struct platform_device *pdev)
goto iounmap_ctrl;
}
+#ifdef CONFIG_DEBUG_FS
+ /*
+* FIXME: needs better naming distinction, as some amalgamation of
+* "caam" and nprop->full_name. The OF name isn't distinctive,
+* but does separate instances
+*/
+ perfmon = (struct caam_perfmon __force *)&ctrl->perfmon;
+
+ ctrlpriv->dfs_root = debugfs_create_dir(dev_name(dev), NULL);
+ ctrlpriv->ctl = debugfs_create_dir("ctl", ctrlpriv->dfs_root);
+#endif
ring = 0;
ridx = 0;
ctrlpriv->total_jobrs = 0;
@@ -650,6 +653,13 @@ static int caam_probe(struct platform_device *pdev)
);
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list. Heh, I was about to ask if it was something I should push towards another maintainer for s5p stuff, but found you listed in that as well. If I am incorrect in that assumption, do let me know whom else I should make aware of this issue. Also let me know if you would like the rest of the kernel panic. Maybe you already have enough to go on and don't need it. Thanks for all that clarity. On Fri, Mar 3, 2017 at 6:04 AM, Herbert Xu wrote: > On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote: >> I do have ECB selected as well: >> DM_CRYPT=y >> CRYPTO_ECB=y >> CRYPTO_XTS=y >> >> name : ecb(aes) >> driver : ecb-aes-s5p >> module : kernel >> priority : 100 >> refcnt : 1 >> selftest : passed >> internal : no >> type : ablkcipher >> async: yes >> blocksize: 16 >> min keysize : 16 >> max keysize : 32 >> ivsize : 0 >> geniv: >> //still no "xts" can be found in the list > > Weird. So you can't find any instances of xts in /proc/crypto > at all? Even if the self-test fails it should still register an > entry there... > > In any case, I think disabling the s5p driver should work at > least. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device
On Thu, 2017-03-02 at 13:11 -0600, Brijesh Singh wrote: > Hi Mark, > > On 03/02/2017 11:39 AM, Mark Rutland wrote: > > On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote: > > > > > > +ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \ > > > ccp-ops.o \ > > > ccp-dev-v3.o \ > > > ccp-dev-v5.o \ > > > - ccp-platform.o \ > > > ccp-dmaengine.o > > > > It looks like ccp-platform.c has morphed into sp-platform.c (judging > > by > > the compatible string and general shape of the code), and the > > original > > ccp-platform.c is no longer built. > > > > Shouldn't ccp-platform.c be deleted by this patch? > > > > Good catch. Both ccp-platform.c and ccp-pci.c should have been > deleted > by this patch. I missed deleting it, will fix in next rev. Don't forget to use -M -C when preparing / sending patches. -- Andy Shevchenko Intel Finland Oy
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote: > I do have ECB selected as well: > DM_CRYPT=y > CRYPTO_ECB=y > CRYPTO_XTS=y > > name : ecb(aes) > driver : ecb-aes-s5p > module : kernel > priority : 100 > refcnt : 1 > selftest : passed > internal : no > type : ablkcipher > async: yes > blocksize: 16 > min keysize : 16 > max keysize : 32 > ivsize : 0 > geniv: > //still no "xts" can be found in the list Weird. So you can't find any instances of xts in /proc/crypto at all? Even if the self-test fails it should still register an entry there... In any case, I think disabling the s5p driver should work at least. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
I do have ECB selected as well: DM_CRYPT=y CRYPTO_ECB=y CRYPTO_XTS=y name : ecb(aes) driver : ecb-aes-s5p module : kernel priority : 100 refcnt : 1 selftest : passed internal : no type : ablkcipher async: yes blocksize: 16 min keysize : 16 max keysize : 32 ivsize : 0 geniv: //still no "xts" can be found in the list I saw this about the regression that sounds similar to my issue, except even when I built-in dm_crypt (no initramfs. just diving straight into system), it still fails: http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23748.html On Fri, Mar 3, 2017 at 3:33 AM, Herbert Xu wrote: > On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote: >> OK, I went ahead and enabled self tests >> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, >> albeit with failures: >> * >> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- >> Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on >> test 1 for xts(ecb-aes-s5p): ret=35 >> Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt: >> Error allocating crypto tfm >> Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding >> target to table >> Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate >> with key file '/dev/urandom': Invalid argument >> * >> (weird that it asked for the passphrase) >> >> But I do question whether the root issue is related to s5p... Maybe >> there is a correlation in the warning, but to me it looks like the >> issue is something else. > > I see. Do you have ECB enabled in your config? The new XTS requires > ECB to be present so that could be your problem. > > There is already a patch on its way to stable to add the Kconfig > select on ECB. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote: > OK, I went ahead and enabled self tests > "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, > albeit with failures: > * > Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- > Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on > test 1 for xts(ecb-aes-s5p): ret=35 > Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt: > Error allocating crypto tfm > Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding > target to table > Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate > with key file '/dev/urandom': Invalid argument > * > (weird that it asked for the passphrase) > > But I do question whether the root issue is related to s5p... Maybe > there is a correlation in the warning, but to me it looks like the > issue is something else. I see. Do you have ECB enabled in your config? The new XTS requires ECB to be present so that could be your problem. There is already a patch on its way to stable to add the Kconfig select on ECB. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.
OK, I went ahead and enabled self tests "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot, albeit with failures: * Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]--- Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on test 1 for xts(ecb-aes-s5p): ret=35 Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt: Error allocating crypto tfm Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding target to table Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate with key file '/dev/urandom': Invalid argument * (weird that it asked for the passphrase) But I do question whether the root issue is related to s5p... Maybe there is a correlation in the warning, but to me it looks like the issue is something else. In my OP, I noted that the xts crypto isn't even found in /proc/crypto in 4.10. I'd think it would at least be listed, even if it isn't used. CBC is listed in /proc/crypto with kernel 4.9.13 and 4.10.1 (cbc-aes-s5p) XTS is listed in /proc/crypto with kernel 4.9.13 but NOT 4.10.1 I should also add that I didn't include other tainted messages since they followed the messages I first posted. I was assuming that when the first issue would work, the others would follow suit. I just didn't want to inundate with possible junk. I still have the log file if you think it would be helpful to post the rest. PS: I also noticed the bounce from my first mail submission because I didn't enable plain-text for the e-mail (marked as spam because the email contained html). I rectified that for this reply. On Thu, Mar 2, 2017 at 10:02 PM, Herbert Xu wrote: > On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote: >> ARM ODroid XU4 >> >> $ cat /proc/config.gz | gunzip | grep XTS >> CONFIG_CRYPTO_XTS=y >> >> $ grep xts /proc/crypto >> //4.9.13 >> name : xts(aes) >> driver : xts(aes-generic) >> //4.10.1 >> >> //cbc can be found though >> >> CRYPTTAB: >> cryptswap1 UUID= /dev/urandom >> swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail >> >> FSTAB: >> /dev/mapper/cryptswap1 none swap sw 0 0 >> >> Boot Log: >> [ 10.535985] [ cut here ] >> [ 10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430 >> skcipher_walk_first+0x13c/0x14c >> [ 10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate >> dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc >> ip_tables x_tables >> [ 10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1 >> [ 10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >> [ 10.574171] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [ 10.581893] [] (show_stack) from [] >> (dump_stack+0x84/0x98) >> [ 10.589073] [] (dump_stack) from [] >> (__warn+0xe8/0x100) >> [ 10.595975] [] (__warn) from [] >> (warn_slowpath_null+0x20/0x28) >> [ 10.603546] [] (warn_slowpath_null) from [] >> (skcipher_walk_first+0x13c/0x14c) >> [ 10.612390] [] (skcipher_walk_first) from [] >> (skcipher_walk_virt+0x1c/0x38) >> [ 10.621056] [] (skcipher_walk_virt) from [] >> (post_crypt+0x38/0x1c4) >> [ 10.629022] [] (post_crypt) from [] >> (decrypt_done+0x4c/0x54) >> [ 10.636389] [] (decrypt_done) from [] >> (s5p_aes_complete+0x70/0xfc) >> [ 10.644274] [] (s5p_aes_complete) from [] >> (s5p_aes_interrupt+0x134/0x1a0) >> [ 10.652771] [] (s5p_aes_interrupt) from [] >> (__handle_irq_event_percpu+0x9c/0x124) > > This looks like a bug in the s5p driver. It's calling the completion > function straight from the IRQ handler, which is triggering the > sanity check in skcipher_walk_first. > > The s5p driver needs to schedule a tasklet to call the completion > function. > > Do you have crypto self-test enabled? If so it should've caught > this at run-time. Otherwise you can disable the s5p driver until > it's fixed. > > Cheers, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
