Re: PBKDF2 support in the linux kernel

[Stephan Mueller]

Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers:

Hi Eric,

> 
> "Not having to rely on any third-party library" is not an excuse to add
> random code to the kernel, which runs in a privileged context.  Please do
> PBKDF2 in userspace instead.

I second that. Besides, if you really need to rely on the kernel crypto API to 
do that because you do not want to add yet another crypto lib, libkcapi has a 
PBKDF2 implementation that uses the kernel crypto API via AF_ALG. I.e. the 
kernel crypto API is used and yet the PBKDF logic is in user space.

http://www.chronox.de/libkcapi.html

Ciao
Stephan

Re: PBKDF2 support in the linux kernel

[Eric Biggers]

Hi Yu,

On Thu, May 24, 2018 at 10:26:12AM +0800, Yu Chen wrote:
> Hi Stephan,
> thanks for your reply,
> On Wed, May 23, 2018 at 1:43 AM Stephan Mueller  wrote:
> 
> > Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen:
> 
> > Hi Yu,
> 
> > > Hi all,
> > > The request is that, we'd like to generate a symmetric key derived from
> > > user provided passphase(not rely on any third-party library). May I
> know if
> > > there is a PBKDF2(Password-Based Key Derivation Function 2) support in
> the
> > > kernel? (https://tools.ietf.org/html/rfc2898#5.2)
> > > We have hmac sha1 in the kernel, do we have plan to port/implement
> > > corresponding PBKDF2 in the kernel too?
> 
> > There is no PBKDF2 support in the kernel.
> 
> I saw that there's already a kdf implementation using SP800-56A
> in security/keys/dh.c, I think I can learn from that and  implement PDKDF2
> using similar code.
> > Ciao
> > Stephan
> Best,
> Yu

"Not having to rely on any third-party library" is not an excuse to add random
code to the kernel, which runs in a privileged context.  Please do PBKDF2 in
userspace instead.

- Eric

Re: PBKDF2 support in the linux kernel

[Yu Chen]

Hi Stephan,
thanks for your reply,
On Wed, May 23, 2018 at 1:43 AM Stephan Mueller  wrote:

> Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen:

> Hi Yu,

> > Hi all,
> > The request is that, we'd like to generate a symmetric key derived from
> > user provided passphase(not rely on any third-party library). May I
know if
> > there is a PBKDF2(Password-Based Key Derivation Function 2) support in
the
> > kernel? (https://tools.ietf.org/html/rfc2898#5.2)
> > We have hmac sha1 in the kernel, do we have plan to port/implement
> > corresponding PBKDF2 in the kernel too?

> There is no PBKDF2 support in the kernel.

I saw that there's already a kdf implementation using SP800-56A
in security/keys/dh.c, I think I can learn from that and  implement PDKDF2
using similar code.
> Ciao
> Stephan
Best,
Yu

[PATCH 3/3] crypto: caam/qi - fix warning in init_cgr()

[Horia Geantă]

Coverity warns about an
"Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)"
when computing the congestion threshold value.

Even though it is highly unlikely for an overflow to happen,
use this as an opportunity to simplify the code.

Signed-off-by: Horia Geantă 
---
 drivers/crypto/caam/qi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/crypto/caam/qi.c b/drivers/crypto/caam/qi.c
index b9480828da38..67f7f8c42c93 100644
--- a/drivers/crypto/caam/qi.c
+++ b/drivers/crypto/caam/qi.c
@@ -657,9 +657,8 @@ static int init_cgr(struct device *qidev)
 {
int ret;
struct qm_mcc_initcgr opts;
-   const u64 cpus = *(u64 *)qman_affine_cpus();
-   const int num_cpus = hweight64(cpus);
-   const u64 val = num_cpus * MAX_RSP_FQ_BACKLOG_PER_CPU;
+   const u64 val = (u64)cpumask_weight(qman_affine_cpus()) *
+   MAX_RSP_FQ_BACKLOG_PER_CPU;
 
ret = qman_alloc_cgrid();
if (ret) {
-- 
2.16.2

[PATCH 1/3] crypto: caam - fix MC firmware detection

[Horia Geantă]

Management Complex (MC) f/w detection is based on CTPR_MS[DPAA2] bit.

This is incorrect since:
-the bit is set for all CAAM blocks integrated in SoCs with a certain
Layerscape Chassis
-some SoCs with LS Chassis don't have an MC block (thus no MC f/w)

To fix this, MC f/w detection will be based on the presence of
"fsl,qoriq-mc" compatible string in the device tree.

Fixes: 297b9cebd2fc0 ("crypto: caam/jr - add support for DPAA2 parts")
Signed-off-by: Horia Geantă 
---
 drivers/crypto/caam/ctrl.c   | 21 -
 drivers/crypto/caam/intern.h |  1 +
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index a28868d5b2d0..538c01f428c1 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -322,9 +322,9 @@ static int caam_remove(struct platform_device *pdev)
 
/*
 * De-initialize RNG state handles initialized by this driver.
-* In case of DPAA 2.x, RNG is managed by MC firmware.
+* In case of SoCs with Management Complex, RNG is managed by MC f/w.
 */
-   if (!caam_dpaa2 && ctrlpriv->rng4_sh_init)
+   if (!ctrlpriv->mc_en && ctrlpriv->rng4_sh_init)
deinstantiate_rng(ctrldev, ctrlpriv->rng4_sh_init);
 
/* Shut down debug views */
@@ -618,11 +618,15 @@ static int caam_probe(struct platform_device *pdev)
/*
 * Enable DECO watchdogs and, if this is a PHYS_ADDR_T_64BIT kernel,
 * long pointers in master configuration register.
-* In case of DPAA 2.x, Management Complex firmware performs
+* In case of SoCs with Management Complex, MC f/w performs
 * the configuration.
 */
caam_dpaa2 = !!(comp_params & CTPR_MS_DPAA2);
-   if (!caam_dpaa2)
+   np = of_find_compatible_node(NULL, NULL, "fsl,qoriq-mc");
+   ctrlpriv->mc_en = !!np;
+   of_node_put(np);
+
+   if (!ctrlpriv->mc_en)
clrsetbits_32(>mcr, MCFGR_AWCACHE_MASK | MCFGR_LONG_PTR,
  MCFGR_AWCACHE_CACH | MCFGR_AWCACHE_BUFF |
  MCFGR_WDENABLE | MCFGR_LARGE_BURST |
@@ -733,9 +737,9 @@ static int caam_probe(struct platform_device *pdev)
/*
 * If SEC has RNG version >= 4 and RNG state handle has not been
 * already instantiated, do RNG instantiation
-* In case of DPAA 2.x, RNG is managed by MC firmware.
+* In case of SoCs with Management Complex, RNG is managed by MC f/w.
 */
-   if (!caam_dpaa2 &&
+   if (!ctrlpriv->mc_en &&
(cha_vid_ls & CHA_ID_LS_RNG_MASK) >> CHA_ID_LS_RNG_SHIFT >= 4) {
ctrlpriv->rng4_sh_init =
rd_reg32(>r4tst[0].rdsta);
@@ -804,9 +808,8 @@ static int caam_probe(struct platform_device *pdev)
/* Report "alive" for developer to see */
dev_info(dev, "device ID = 0x%016llx (Era %d)\n", caam_id,
 ctrlpriv->era);
-   dev_info(dev, "job rings = %d, qi = %d, dpaa2 = %s\n",
-ctrlpriv->total_jobrs, ctrlpriv->qi_present,
-caam_dpaa2 ? "yes" : "no");
+   dev_info(dev, "job rings = %d, qi = %d\n",
+ctrlpriv->total_jobrs, ctrlpriv->qi_present);
 
 #ifdef CONFIG_DEBUG_FS
debugfs_create_file("rq_dequeued", S_IRUSR | S_IRGRP | S_IROTH,
diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
index 7696a774a362..babc78abd155 100644
--- a/drivers/crypto/caam/intern.h
+++ b/drivers/crypto/caam/intern.h
@@ -82,6 +82,7 @@ struct caam_drv_private {
 */
u8 total_jobrs; /* Total Job Rings in device */
u8 qi_present;  /* Nonzero if QI present in device */
+   u8 mc_en;   /* Nonzero if MC f/w is active */
int secvio_irq; /* Security violation interrupt number */
int virt_en;/* Virtualization enabled in CAAM */
int era;/* CAAM Era (internal HW revision) */
-- 
2.16.2

[PATCH 2/3] crypto: caam - fix rfc4543 descriptors

[Horia Geantă]

In some cases the CCB DMA-based internal transfer started by the MOVE
command (src=M3 register, dst=descriptor buffer) does not finish
in time and DECO executes the unpatched descriptor.
This leads eventually to a DECO Watchdog Timer timeout error.

To make sure the transfer ends, change the MOVE command to be blocking.

Signed-off-by: Horia Geantă 
---
 drivers/crypto/caam/caamalg_desc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/caam/caamalg_desc.c 
b/drivers/crypto/caam/caamalg_desc.c
index 8ae7a1be7dfd..a408edd84f34 100644
--- a/drivers/crypto/caam/caamalg_desc.c
+++ b/drivers/crypto/caam/caamalg_desc.c
@@ -1093,7 +1093,7 @@ void cnstr_shdsc_rfc4543_encap(u32 * const desc, struct 
alginfo *cdata,
read_move_cmd = append_move(desc, MOVE_SRC_DESCBUF | MOVE_DEST_MATH3 |
(0x6 << MOVE_LEN_SHIFT));
write_move_cmd = append_move(desc, MOVE_SRC_MATH3 | MOVE_DEST_DESCBUF |
-(0x8 << MOVE_LEN_SHIFT));
+(0x8 << MOVE_LEN_SHIFT) | MOVE_WAITCOMP);
 
/* Will read assoclen + cryptlen bytes */
append_math_sub(desc, VARSEQINLEN, SEQINLEN, REG0, CAAM_CMD_SZ);
@@ -1178,7 +1178,7 @@ void cnstr_shdsc_rfc4543_decap(u32 * const desc, struct 
alginfo *cdata,
read_move_cmd = append_move(desc, MOVE_SRC_DESCBUF | MOVE_DEST_MATH3 |
(0x6 << MOVE_LEN_SHIFT));
write_move_cmd = append_move(desc, MOVE_SRC_MATH3 | MOVE_DEST_DESCBUF |
-(0x8 << MOVE_LEN_SHIFT));
+(0x8 << MOVE_LEN_SHIFT) | MOVE_WAITCOMP);
 
/* Will read assoclen + cryptlen bytes */
append_math_sub(desc, VARSEQINLEN, SEQOUTLEN, REG0, CAAM_CMD_SZ);
-- 
2.16.2