Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. Do you have any ideas ? Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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
Re: DRBG seeding
On Fri, Apr 17, 2015 at 02:48:51PM +0200, Stephan Mueller wrote: Do you really think that this is possible? If the DRBG becomes the stdrng, you would imply that those callers (e.g. IPSEC) may suffer from a long block (and with long I mean not just seconds, but minutes). It's only 49 bytes for every 64K so I think it's reasonable. The only reason someone would use this is to comply with the standard and this is what the standard requires so I don't see how we can do anything else. Furthermore, I fail to see the difference between the current default stdrng (krng -- which is just get_random_bytes in disguise). Thus, the current situation with the DRBG seeding is not different from the non-DRBG use case. The difference is that krng doesn't have to satisfy any standard. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
Re: DRBG seeding
Am Freitag, 17. April 2015, 10:14:30 schrieb Herbert Xu: Hi Herbert, On Fri, Apr 17, 2015 at 03:19:17AM +0200, Stephan Mueller wrote: 1. during initialization of a DRBG instance, seed from get_random_bytes to have a DRBG state that is seeded and usable. I think we either need to use real entropy and block, or mark the DRBG unusable until such a time that it has been seeded with real entropy. Do you really think that this is possible? If the DRBG becomes the stdrng, you would imply that those callers (e.g. IPSEC) may suffer from a long block (and with long I mean not just seconds, but minutes). Furthermore, I fail to see the difference between the current default stdrng (krng -- which is just get_random_bytes in disguise). Thus, the current situation with the DRBG seeding is not different from the non-DRBG use case. Therefore, I still think we: - need to satisfy users with an immediate need for random numbers immediately after instantiating the DRBG - need to obtain /dev/random-like entropy as we can get hold of it. Just as a side note, about 2 years ago, I offered a solution that also provides instant entropy at the time you need it -- see [1]. Unfortunately, it was rejected based on grounds I cannot fully comprehend [1] https://lkml.org/lkml/2013/10/11/582 -- Ciao Stephan -- 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/4] crypto: drbg - replace spinlock with mutex
The DRBG shall hold a long term lock. Therefore, the lock is changed to
a mutex which implies that the DRBG can only be used in process context.
The lock now guards the instantiation as well as the entire DRBG
generation operation. Therefore, multiple callers are fully serialized
when generating a random number.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/drbg.c | 22 ++
include/crypto/drbg.h | 4 ++--
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index c8a083c..19916ea 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1181,7 +1181,6 @@ static inline int drbg_alloc_state(struct drbg_state
*drbg)
if (!drbg-scratchpad)
goto err;
}
- spin_lock_init(drbg-drbg_lock);
return 0;
err:
@@ -1349,7 +1348,9 @@ static int drbg_generate_long(struct drbg_state *drbg,
unsigned int chunk = 0;
slice = ((buflen - len) / drbg_max_request_bytes(drbg));
chunk = slice ? drbg_max_request_bytes(drbg) : (buflen - len);
+ mutex_lock(drbg-drbg_mutex);
tmplen = drbg_generate(drbg, buf + len, chunk, addtl);
+ mutex_unlock(drbg-drbg_mutex);
if (0 = tmplen)
return tmplen;
len += tmplen;
@@ -1377,10 +1378,12 @@ static int drbg_generate_long(struct drbg_state *drbg,
static int drbg_instantiate(struct drbg_state *drbg, struct drbg_string *pers,
int coreref, bool pr)
{
- int ret = -ENOMEM;
+ int ret = -EOPNOTSUPP;
pr_devel(DRBG: Initializing DRBG core %d with prediction resistance
%s\n, coreref, pr ? enabled : disabled);
+ mutex_init(drbg-drbg_mutex);
+ mutex_lock(drbg-drbg_mutex);
drbg-core = drbg_cores[coreref];
drbg-pr = pr;
drbg-seeded = false;
@@ -1401,7 +1404,7 @@ static int drbg_instantiate(struct drbg_state *drbg,
struct drbg_string *pers,
break;
#endif /* CONFIG_CRYPTO_DRBG_CTR */
default:
- return -EOPNOTSUPP;
+ goto unlock;
}
/* 9.1 step 1 is implicit with the selected DRBG type */
@@ -1416,7 +1419,7 @@ static int drbg_instantiate(struct drbg_state *drbg,
struct drbg_string *pers,
ret = drbg_alloc_state(drbg);
if (ret)
- return ret;
+ goto unlock;
ret = -EFAULT;
if (drbg-d_ops-crypto_init(drbg))
@@ -1426,10 +1429,13 @@ static int drbg_instantiate(struct drbg_state *drbg,
struct drbg_string *pers,
if (ret)
goto err;
+ mutex_unlock(drbg-drbg_mutex);
return 0;
err:
drbg_dealloc_state(drbg);
+unlock:
+ mutex_unlock(drbg-drbg_mutex);
return ret;
}
@@ -1444,10 +1450,10 @@ err:
*/
static int drbg_uninstantiate(struct drbg_state *drbg)
{
- spin_lock_bh(drbg-drbg_lock);
+ mutex_lock(drbg-drbg_mutex);
drbg_dealloc_state(drbg);
/* no scrubbing of test_data -- this shall survive an uninstantiate */
- spin_unlock_bh(drbg-drbg_lock);
+ mutex_unlock(drbg-drbg_mutex);
return 0;
}
@@ -1462,9 +1468,9 @@ static inline void drbg_set_testdata(struct drbg_state
*drbg,
{
if (!test_data || !test_data-testentropy)
return;
- spin_lock_bh(drbg-drbg_lock);
+ mutex_lock(drbg-drbg_mutex);;
drbg-test_data = test_data;
- spin_unlock_bh(drbg-drbg_lock);
+ mutex_unlock(drbg-drbg_mutex);
}
/***
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index 5186f75..a43a7ed 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -49,7 +49,7 @@
#include crypto/internal/rng.h
#include crypto/rng.h
#include linux/fips.h
-#include linux/spinlock.h
+#include linux/mutex.h
#include linux/list.h
/*
@@ -104,7 +104,7 @@ struct drbg_test_data {
};
struct drbg_state {
- spinlock_t drbg_lock; /* lock around DRBG */
+ struct mutex drbg_mutex;/* lock around DRBG */
unsigned char *V; /* internal state 10.1.1.1 1a) */
/* hash: static value 10.1.1.1 1b) hmac / ctr: key */
unsigned char *C;
--
2.1.0
--
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 2/4] crypto: drbg - do not create shadow copy
The creation of a shadow copy is intended to only hold a short term
lock. But the drawback is that parallel users have a very similar DRBG
state which only differs by a high-resolution time stamp.
As the locking is changed to use a long-term lock to avoid such similar
DRBG states, the entire creation and maintenance of a shadow copy can be
removed.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/drbg.c | 122 ++
1 file changed, 11 insertions(+), 111 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 8d2944f..c8a083c 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1189,79 +1189,6 @@ err:
return ret;
}
-/*
- * Strategy to avoid holding long term locks: generate a shadow copy of DRBG
- * and perform all operations on this shadow copy. After finishing, restore
- * the updated state of the shadow copy into original drbg state. This way,
- * only the read and write operations of the original drbg state must be
- * locked
- */
-static inline void drbg_copy_drbg(struct drbg_state *src,
- struct drbg_state *dst)
-{
- if (!src || !dst)
- return;
- memcpy(dst-V, src-V, drbg_statelen(src));
- memcpy(dst-C, src-C, drbg_statelen(src));
- dst-reseed_ctr = src-reseed_ctr;
- dst-seeded = src-seeded;
- dst-pr = src-pr;
-#ifdef CONFIG_CRYPTO_FIPS
- dst-fips_primed = src-fips_primed;
- memcpy(dst-prev, src-prev, drbg_blocklen(src));
-#endif
- /*
-* Not copied:
-* scratchpad is initialized drbg_alloc_state;
-* priv_data is initialized with call to crypto_init;
-* d_ops and core are set outside, as these parameters are const;
-* test_data is set outside to prevent it being copied back.
-*/
-}
-
-static int drbg_make_shadow(struct drbg_state *drbg, struct drbg_state
**shadow)
-{
- int ret = -ENOMEM;
- struct drbg_state *tmp = NULL;
-
- tmp = kzalloc(sizeof(struct drbg_state), GFP_KERNEL);
- if (!tmp)
- return -ENOMEM;
-
- /* read-only data as they are defined as const, no lock needed */
- tmp-core = drbg-core;
- tmp-d_ops = drbg-d_ops;
-
- ret = drbg_alloc_state(tmp);
- if (ret)
- goto err;
-
- spin_lock_bh(drbg-drbg_lock);
- drbg_copy_drbg(drbg, tmp);
- /* only make a link to the test buffer, as we only read that data */
- tmp-test_data = drbg-test_data;
- spin_unlock_bh(drbg-drbg_lock);
- *shadow = tmp;
- return 0;
-
-err:
- kzfree(tmp);
- return ret;
-}
-
-static void drbg_restore_shadow(struct drbg_state *drbg,
- struct drbg_state **shadow)
-{
- struct drbg_state *tmp = *shadow;
-
- spin_lock_bh(drbg-drbg_lock);
- drbg_copy_drbg(tmp, drbg);
- spin_unlock_bh(drbg-drbg_lock);
- drbg_dealloc_state(tmp);
- kzfree(tmp);
- *shadow = NULL;
-}
-
/*
* DRBG interface functions
*/
@@ -1287,13 +1214,7 @@ static int drbg_generate(struct drbg_state *drbg,
struct drbg_string *addtl)
{
int len = 0;
- struct drbg_state *shadow = NULL;
LIST_HEAD(addtllist);
- struct drbg_string timestamp;
- union {
- cycles_t cycles;
- unsigned char char_cycles[sizeof(cycles_t)];
- } now;
if (0 == buflen || !buf) {
pr_devel(DRBG: no output buffer provided\n);
@@ -1304,15 +1225,9 @@ static int drbg_generate(struct drbg_state *drbg,
return -EINVAL;
}
- len = drbg_make_shadow(drbg, shadow);
- if (len) {
- pr_devel(DRBG: shadow copy cannot be generated\n);
- return len;
- }
-
/* 9.3.1 step 2 */
len = -EINVAL;
- if (buflen (drbg_max_request_bytes(shadow))) {
+ if (buflen (drbg_max_request_bytes(drbg))) {
pr_devel(DRBG: requested random numbers too large %u\n,
buflen);
goto err;
@@ -1321,7 +1236,7 @@ static int drbg_generate(struct drbg_state *drbg,
/* 9.3.1 step 3 is implicit with the chosen DRBG */
/* 9.3.1 step 4 */
- if (addtl addtl-len (drbg_max_addtl(shadow))) {
+ if (addtl addtl-len (drbg_max_addtl(drbg))) {
pr_devel(DRBG: additional information string too long %zu\n,
addtl-len);
goto err;
@@ -1332,46 +1247,34 @@ static int drbg_generate(struct drbg_state *drbg,
* 9.3.1 step 6 and 9 supplemented by 9.3.2 step c is implemented
* here. The spec is a bit convoluted here, we make it simpler.
*/
- if ((drbg_max_requests(shadow)) shadow-reseed_ctr)
-
[PATCH 4/4] crypto: drbg - leave cipher handles operational
As the DRBG does not operate on shadow copies of the DRBG instance
any more, the cipher handles only need to be allocated once during
initalization time and deallocated during uninstantiate time.
Signed-off-by: Stephan Mueller smuel...@chronox.de
---
crypto/drbg.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 19916ea..4289624 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1249,11 +1249,6 @@ static int drbg_generate(struct drbg_state *drbg,
if ((drbg_max_requests(drbg)) drbg-reseed_ctr)
drbg-seeded = false;
- /* allocate cipher handle */
- len = drbg-d_ops-crypto_init(drbg);
- if (len)
- goto err;
-
if (drbg-pr || !drbg-seeded) {
pr_devel(DRBG: reseeding before generation (prediction
resistance: %s, state %s)\n,
@@ -1325,7 +1320,6 @@ static int drbg_generate(struct drbg_state *drbg,
*/
len = 0;
err:
- drbg-d_ops-crypto_fini(drbg);
return len;
}
@@ -1425,9 +1419,10 @@ static int drbg_instantiate(struct drbg_state *drbg,
struct drbg_string *pers,
if (drbg-d_ops-crypto_init(drbg))
goto err;
ret = drbg_seed(drbg, pers, false);
- drbg-d_ops-crypto_fini(drbg);
- if (ret)
+ if (ret) {
+ drbg-d_ops-crypto_fini(drbg);
goto err;
+ }
mutex_unlock(drbg-drbg_mutex);
return 0;
@@ -1451,6 +1446,7 @@ unlock:
static int drbg_uninstantiate(struct drbg_state *drbg)
{
mutex_lock(drbg-drbg_mutex);
+ drbg-d_ops-crypto_fini(drbg);
drbg_dealloc_state(drbg);
/* no scrubbing of test_data -- this shall survive an uninstantiate */
mutex_unlock(drbg-drbg_mutex);
--
2.1.0
--
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 1/4] cryoto: drbg - clear all temporary memory
The buffer uses for temporary data must be cleared entirely. In AES192 the used buffer is drbg_statelen(drbg) + drbg_blocklen(drbg) as documented in the comment above drbg_ctr_df. This patch ensures that the temp buffer is completely wiped. Signed-off-by: Stephan Mueller smuel...@chronox.de --- crypto/drbg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index b69409c..8d2944f 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -487,7 +487,7 @@ static int drbg_ctr_df(struct drbg_state *drbg, out: memset(iv, 0, drbg_blocklen(drbg)); - memset(temp, 0, drbg_statelen(drbg)); + memset(temp, 0, drbg_statelen(drbg) + drbg_blocklen(drbg)); memset(pad, 0, drbg_blocklen(drbg)); return ret; } -- 2.1.0 -- 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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. However, the old driver doesn't try to reserve the region, it directly uses an ioremap(). So if the new driver is loaded first, then the old one will manage to be loaded too. I think that just adding a request_region()/release_region() (or converting the ioremap in a devm_ioremap_resource() in the old driver would be enough. Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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 v3 13/17] crypto: talitos - adapt interrupts and reset functions to SEC1
This patch adapts the interrupts handling and reset function for
SEC1. On SEC1, registers are almost similar to SEC2+, but bits
are sometimes located at different places. So we need to define
TALITOS1 and TALITOS2 versions of some fields, and manage according
to whether it is SEC1 or SEC2.
On SEC1, only one interrupt vector is dedicated to the SEC, so only
interrupt_4ch is needed.
On SEC1, interrupts are enabled by clearing related bits in IMR,
while on SEC2, interrupts are enabled by seting the bits in IMR.
SEC1 also performs parity verification in the DES Unit. We have
to disable this feature because the test vectors provided in
the kernel have parity errors.
In reset functions, only SEC2 supports continuation after error.
For SEC1, we have to reset in all cases.
For errors handling, SEC2+ names have been kept, but displayed
text have been amended to reflect exact meaning on SEC1.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 227 +++
drivers/crypto/talitos.h | 39 +---
2 files changed, 199 insertions(+), 67 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 6d77699..1265405 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -124,12 +124,23 @@ static int reset_channel(struct device *dev, int ch)
{
struct talitos_private *priv = dev_get_drvdata(dev);
unsigned int timeout = TALITOS_TIMEOUT;
+ bool is_sec1 = has_ftr_sec1(priv);
- setbits32(priv-chan[ch].reg + TALITOS_CCCR, TALITOS_CCCR_RESET);
+ if (is_sec1) {
+ setbits32(priv-chan[ch].reg + TALITOS_CCCR_LO,
+ TALITOS1_CCCR_LO_RESET);
- while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR) TALITOS_CCCR_RESET)
- --timeout)
- cpu_relax();
+ while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR_LO)
+ TALITOS1_CCCR_LO_RESET) --timeout)
+ cpu_relax();
+ } else {
+ setbits32(priv-chan[ch].reg + TALITOS_CCCR,
+ TALITOS2_CCCR_RESET);
+
+ while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR)
+ TALITOS2_CCCR_RESET) --timeout)
+ cpu_relax();
+ }
if (timeout == 0) {
dev_err(dev, failed to reset channel %d\n, ch);
@@ -152,11 +163,12 @@ static int reset_device(struct device *dev)
{
struct talitos_private *priv = dev_get_drvdata(dev);
unsigned int timeout = TALITOS_TIMEOUT;
- u32 mcr = TALITOS_MCR_SWR;
+ bool is_sec1 = has_ftr_sec1(priv);
+ u32 mcr = is_sec1 ? TALITOS1_MCR_SWR : TALITOS2_MCR_SWR;
setbits32(priv-reg + TALITOS_MCR, mcr);
- while ((in_be32(priv-reg + TALITOS_MCR) TALITOS_MCR_SWR)
+ while ((in_be32(priv-reg + TALITOS_MCR) mcr)
--timeout)
cpu_relax();
@@ -180,6 +192,7 @@ static int init_device(struct device *dev)
{
struct talitos_private *priv = dev_get_drvdata(dev);
int ch, err;
+ bool is_sec1 = has_ftr_sec1(priv);
/*
* Master reset
@@ -203,8 +216,15 @@ static int init_device(struct device *dev)
}
/* enable channel done and error interrupts */
- setbits32(priv-reg + TALITOS_IMR, TALITOS_IMR_INIT);
- setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
+ if (is_sec1) {
+ clrbits32(priv-reg + TALITOS_IMR, TALITOS1_IMR_INIT);
+ clrbits32(priv-reg + TALITOS_IMR_LO, TALITOS1_IMR_LO_INIT);
+ /* disable parity error check in DEU (erroneous? test vect.) */
+ setbits32(priv-reg_deu + TALITOS_EUICR, TALITOS1_DEUICR_KPE);
+ } else {
+ setbits32(priv-reg + TALITOS_IMR, TALITOS2_IMR_INIT);
+ setbits32(priv-reg + TALITOS_IMR_LO, TALITOS2_IMR_LO_INIT);
+ }
/* disable integrity check error interrupts (use writeback instead) */
if (priv-features TALITOS_FTR_HW_AUTH_CHECK)
@@ -349,8 +369,37 @@ static void flush_channel(struct device *dev, int ch, int
error, int reset_ch)
/*
* process completed requests for channels that have done status
*/
-#define DEF_TALITOS_DONE(name, ch_done_mask) \
-static void talitos_done_##name(unsigned long data)\
+#define DEF_TALITOS1_DONE(name, ch_done_mask) \
+static void talitos1_done_##name(unsigned long data) \
+{ \
+ struct device *dev = (struct device *)data; \
+ struct talitos_private *priv = dev_get_drvdata(dev);\
+ unsigned long flags;\
+ \
+ if (ch_done_mask 0x1000)
[PATCH v3 00/17] crypto: talitos - Add support for SEC1
The purpose of this set of patchs is to add to talitos crypto driver the support for the SEC1 version of the security engine, which is found in mpc885 and mpc8272 processors. v3 is a complete rework of the patchset. Since a kernel can be built with support for both MPC82xx and MPC83xx at the same time, talitos driver shall support both SEC1 and SEC2+ at the same time. Based on cryptodev-2.6 tree Christophe Leroy (17): crypto: talitos - Use zero entry to init descriptors ptrs to zero crypto: talitos - Refactor the sg in/out chain allocation crypto: talitos - talitos_ptr renamed ptr for more lisibility crypto: talitos - Add a helper function to clear j_extent field crypto: talitos - remove param 'extent' in map_single_talitos_ptr() crypto: talitos - helper function for ptr len crypto: talitos - enhanced talitos_desc struct for SEC1 crypto: talitos - add sub-choice in talitos CONFIG for SEC1 crypto: talitos - Add a feature to tag SEC1 crypto: talitos - fill in talitos descriptor iaw SEC1 or SEC2+ crypto: talitos - adaptation of talitos_submit() for SEC1 crypto: talitos - base address for Execution Units crypto: talitos - adapt interrupts and reset functions to SEC1 crypto: talitos - implement scatter/gather copy for SEC1 crypto: talitos - SEC1 bugs on 0 data hash crypto: talitos - Add fsl,sec1.0 compatible crypto: talitos - Update DT bindings with SEC1 .../devicetree/bindings/crypto/fsl-sec2.txt| 6 +- drivers/crypto/Kconfig | 18 + drivers/crypto/talitos.c | 727 +++-- drivers/crypto/talitos.h | 153 +++-- 4 files changed, 644 insertions(+), 260 deletions(-) -- 2.1.0 -- 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 v3 10/17] crypto: talitos - fill in talitos descriptor iaw SEC1 or SEC2+
talitos descriptor is slightly different for SEC1 and SEC2+, so
lets the helper function that fills the descriptor take into account
the type of SEC.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 105 ++-
1 file changed, 67 insertions(+), 38 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index db95023..678b528 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -55,25 +55,38 @@
#include talitos.h
-static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr)
+static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr,
+ bool is_sec1)
{
ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
- ptr-eptr = upper_32_bits(dma_addr);
+ if (!is_sec1)
+ ptr-eptr = upper_32_bits(dma_addr);
}
-static void to_talitos_ptr_len(struct talitos_ptr *ptr, unsigned short len)
+static void to_talitos_ptr_len(struct talitos_ptr *ptr, unsigned short len,
+ bool is_sec1)
{
- ptr-len = cpu_to_be16(len);
+ if (is_sec1) {
+ ptr-res = 0;
+ ptr-len1 = cpu_to_be16(len);
+ } else {
+ ptr-len = cpu_to_be16(len);
+ }
}
-static unsigned short from_talitos_ptr_len(struct talitos_ptr *ptr)
+static unsigned short from_talitos_ptr_len(struct talitos_ptr *ptr,
+ bool is_sec1)
{
- return be16_to_cpu(ptr-len);
+ if (is_sec1)
+ return be16_to_cpu(ptr-len1);
+ else
+ return be16_to_cpu(ptr-len);
}
-static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr)
+static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr, bool is_sec1)
{
- ptr-j_extent = 0;
+ if (!is_sec1)
+ ptr-j_extent = 0;
}
/*
@@ -85,10 +98,12 @@ static void map_single_talitos_ptr(struct device *dev,
enum dma_data_direction dir)
{
dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
- to_talitos_ptr_len(ptr, len);
- to_talitos_ptr(ptr, dma_addr);
- to_talitos_ptr_extent_clear(ptr);
+ to_talitos_ptr_len(ptr, len, is_sec1);
+ to_talitos_ptr(ptr, dma_addr, is_sec1);
+ to_talitos_ptr_extent_clear(ptr, is_sec1);
}
/*
@@ -98,8 +113,11 @@ static void unmap_single_talitos_ptr(struct device *dev,
struct talitos_ptr *ptr,
enum dma_data_direction dir)
{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
+
dma_unmap_single(dev, be32_to_cpu(ptr-ptr),
-from_talitos_ptr_len(ptr), dir);
+from_talitos_ptr_len(ptr, is_sec1), dir);
}
static int reset_channel(struct device *dev, int ch)
@@ -922,7 +940,7 @@ static int sg_to_link_tbl(struct scatterlist *sg, int
sg_count,
int n_sg = sg_count;
while (n_sg--) {
- to_talitos_ptr(link_tbl_ptr, sg_dma_address(sg));
+ to_talitos_ptr(link_tbl_ptr, sg_dma_address(sg), 0);
link_tbl_ptr-len = cpu_to_be16(sg_dma_len(sg));
link_tbl_ptr-j_extent = 0;
link_tbl_ptr++;
@@ -976,7 +994,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
struct talitos_ptr *tbl_ptr = edesc-link_tbl[tbl_off];
to_talitos_ptr(desc-ptr[1], edesc-dma_link_tbl + tbl_off *
- sizeof(struct talitos_ptr));
+ sizeof(struct talitos_ptr), 0);
desc-ptr[1].j_extent = DESC_PTR_LNKTBL_JUMP;
/* assoc_nents - 1 entries for assoc, 1 for IV */
@@ -987,7 +1005,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
tbl_ptr += sg_count - 1;
tbl_ptr-j_extent = 0;
tbl_ptr++;
- to_talitos_ptr(tbl_ptr, edesc-iv_dma);
+ to_talitos_ptr(tbl_ptr, edesc-iv_dma, 0);
tbl_ptr-len = cpu_to_be16(ivsize);
tbl_ptr-j_extent = DESC_PTR_LNKTBL_RETURN;
@@ -996,14 +1014,14 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
} else {
if (areq-assoclen)
to_talitos_ptr(desc-ptr[1],
- sg_dma_address(areq-assoc));
+ sg_dma_address(areq-assoc), 0);
else
- to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
+ to_talitos_ptr(desc-ptr[1], edesc-iv_dma, 0);
desc-ptr[1].j_extent = 0;
}
/* cipher iv */
-
[PATCH v3 02/17] crypto: talitos - Refactor the sg in/out chain allocation
This patch refactors the handling of the input and output data that is quite
similar in several functions
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 159 ---
1 file changed, 81 insertions(+), 78 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 7bf1b2b..5a7e345 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1327,16 +1327,23 @@ static int ablkcipher_setkey(struct crypto_ablkcipher
*cipher,
return 0;
}
+static void unmap_sg_talitos_ptr(struct device *dev, struct scatterlist *src,
+struct scatterlist *dst, unsigned int len,
+struct talitos_edesc *edesc)
+{
+ talitos_sg_unmap(dev, edesc, src, dst);
+}
+
static void common_nonsnoop_unmap(struct device *dev,
struct talitos_edesc *edesc,
struct ablkcipher_request *areq)
{
unmap_single_talitos_ptr(dev, edesc-desc.ptr[5], DMA_FROM_DEVICE);
+
+ unmap_sg_talitos_ptr(dev, areq-src, areq-dst, areq-nbytes, edesc);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[2], DMA_TO_DEVICE);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[1], DMA_TO_DEVICE);
- talitos_sg_unmap(dev, edesc, areq-src, areq-dst);
-
if (edesc-dma_len)
dma_unmap_single(dev, edesc-dma_link_tbl, edesc-dma_len,
DMA_BIDIRECTIONAL);
@@ -1358,6 +1365,65 @@ static void ablkcipher_done(struct device *dev,
areq-base.complete(areq-base, err);
}
+int map_sg_in_talitos_ptr(struct device *dev, struct scatterlist *src,
+ unsigned int len, struct talitos_edesc *edesc,
+ enum dma_data_direction dir, struct talitos_ptr *ptr)
+{
+ int sg_count;
+
+ ptr-len = cpu_to_be16(len);
+ ptr-j_extent = 0;
+
+ sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
+ edesc-src_chained);
+
+ if (sg_count == 1) {
+ to_talitos_ptr(ptr, sg_dma_address(src));
+ } else {
+ sg_count = sg_to_link_tbl(src, sg_count, len,
+ edesc-link_tbl[0]);
+ if (sg_count 1) {
+ to_talitos_ptr(ptr, edesc-dma_link_tbl);
+ ptr-j_extent |= DESC_PTR_LNKTBL_JUMP;
+ dma_sync_single_for_device(dev, edesc-dma_link_tbl,
+ edesc-dma_len,
+ DMA_BIDIRECTIONAL);
+ } else {
+ /* Only one segment now, so no link tbl needed */
+ to_talitos_ptr(ptr, sg_dma_address(src));
+ }
+ }
+ return sg_count;
+}
+
+void map_sg_out_talitos_ptr(struct device *dev, struct scatterlist *dst,
+ unsigned int len, struct talitos_edesc *edesc,
+ enum dma_data_direction dir,
+ struct talitos_ptr *ptr, int sg_count)
+{
+ ptr-len = cpu_to_be16(len);
+ ptr-j_extent = 0;
+
+ if (dir != DMA_NONE)
+ sg_count = talitos_map_sg(dev, dst, edesc-dst_nents ? : 1,
+ dir, edesc-dst_chained);
+
+ if (sg_count == 1) {
+ to_talitos_ptr(ptr, sg_dma_address(dst));
+ } else {
+ struct talitos_ptr *link_tbl_ptr =
+ edesc-link_tbl[edesc-src_nents + 1];
+
+ to_talitos_ptr(ptr, edesc-dma_link_tbl +
+ (edesc-src_nents + 1) *
+ sizeof(struct talitos_ptr));
+ ptr-j_extent |= DESC_PTR_LNKTBL_JUMP;
+ sg_count = sg_to_link_tbl(dst, sg_count, len, link_tbl_ptr);
+ dma_sync_single_for_device(dev, edesc-dma_link_tbl,
+ edesc-dma_len, DMA_BIDIRECTIONAL);
+ }
+}
+
static int common_nonsnoop(struct talitos_edesc *edesc,
struct ablkcipher_request *areq,
void (*callback) (struct device *dev,
@@ -1387,56 +1453,16 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/*
* cipher in
*/
- desc-ptr[3].len = cpu_to_be16(cryptlen);
- desc-ptr[3].j_extent = 0;
-
- sg_count = talitos_map_sg(dev, areq-src, edesc-src_nents ? : 1,
- (areq-src == areq-dst) ? DMA_BIDIRECTIONAL
- : DMA_TO_DEVICE,
- edesc-src_chained);
-
- if (sg_count == 1) {
- to_talitos_ptr(desc-ptr[3], sg_dma_address(areq-src));
- } else {
- sg_count = sg_to_link_tbl(areq-src,
[PATCH v3 07/17] crypto: talitos - enhanced talitos_desc struct for SEC1
This patch enhances the talitos_desc struct with fields for SEC1.
SEC1 has only one header field, and has a 'next_desc' field in
addition.
This mixed descriptor will continue to fit SEC2, and for SEC1
we will recopy hdr value into hdr1 value in talitos_submit()
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 61a1405..f078da1 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -37,9 +37,17 @@
/* descriptor pointer entry */
struct talitos_ptr {
- __be16 len; /* length */
- u8 j_extent;/* jump to sg link table and/or extent */
- u8 eptr;/* extended address */
+ union {
+ struct {/* SEC2 format */
+ __be16 len; /* length */
+ u8 j_extent;/* jump to sg link table and/or extent*/
+ u8 eptr;/* extended address */
+ };
+ struct {/* SEC1 format */
+ __be16 res;
+ __be16 len1;/* length */
+ };
+ };
__be32 ptr; /* address */
};
@@ -53,8 +61,12 @@ static const struct talitos_ptr zero_entry = {
/* descriptor */
struct talitos_desc {
__be32 hdr; /* header high bits */
- __be32 hdr_lo; /* header low bits */
+ union {
+ __be32 hdr_lo; /* header low bits */
+ __be32 hdr1;/* header for SEC1 */
+ };
struct talitos_ptr ptr[7]; /* ptr/len pair array */
+ __be32 next_desc; /* next descriptor (SEC1) */
};
/**
--
2.1.0
--
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 v3 03/17] crypto: talitos - talitos_ptr renamed ptr for more lisibility
Linux CodyingStyle recommends to use short variables for local
variables. ptr is just good enough for those 3 lines functions.
It helps keep single lines shorter than 80 characters.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 5a7e345..fca0aed 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -55,37 +55,37 @@
#include talitos.h
-static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t
dma_addr)
+static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr)
{
- talitos_ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
- talitos_ptr-eptr = upper_32_bits(dma_addr);
+ ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
+ ptr-eptr = upper_32_bits(dma_addr);
}
/*
* map virtual single (contiguous) pointer to h/w descriptor pointer
*/
static void map_single_talitos_ptr(struct device *dev,
- struct talitos_ptr *talitos_ptr,
+ struct talitos_ptr *ptr,
unsigned short len, void *data,
unsigned char extent,
enum dma_data_direction dir)
{
dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
- talitos_ptr-len = cpu_to_be16(len);
- to_talitos_ptr(talitos_ptr, dma_addr);
- talitos_ptr-j_extent = extent;
+ ptr-len = cpu_to_be16(len);
+ to_talitos_ptr(ptr, dma_addr);
+ ptr-j_extent = extent;
}
/*
* unmap bus single (contiguous) h/w descriptor pointer
*/
static void unmap_single_talitos_ptr(struct device *dev,
-struct talitos_ptr *talitos_ptr,
+struct talitos_ptr *ptr,
enum dma_data_direction dir)
{
- dma_unmap_single(dev, be32_to_cpu(talitos_ptr-ptr),
-be16_to_cpu(talitos_ptr-len), dir);
+ dma_unmap_single(dev, be32_to_cpu(ptr-ptr),
+be16_to_cpu(ptr-len), dir);
}
static int reset_channel(struct device *dev, int ch)
--
2.1.0
--
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 v3 05/17] crypto: talitos - remove param 'extent' in map_single_talitos_ptr()
map_single_talitos_ptr() is always called with extent == 0, so lets remove this
unused parameter
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c93f79b..81e5636 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -72,14 +72,13 @@ static void to_talitos_ptr_extent_clear(struct talitos_ptr
*ptr)
static void map_single_talitos_ptr(struct device *dev,
struct talitos_ptr *ptr,
unsigned short len, void *data,
- unsigned char extent,
enum dma_data_direction dir)
{
dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
ptr-len = cpu_to_be16(len);
to_talitos_ptr(ptr, dma_addr);
- ptr-j_extent = extent;
+ to_talitos_ptr_extent_clear(ptr);
}
/*
@@ -958,7 +957,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
/* hmac key */
map_single_talitos_ptr(dev, desc-ptr[0], ctx-authkeylen, ctx-key,
- 0, DMA_TO_DEVICE);
+ DMA_TO_DEVICE);
/* hmac data */
desc-ptr[1].len = cpu_to_be16(areq-assoclen + ivsize);
@@ -1002,7 +1001,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
/* cipher key */
map_single_talitos_ptr(dev, desc-ptr[3], ctx-enckeylen,
- (char *)ctx-key + ctx-authkeylen, 0,
+ (char *)ctx-key + ctx-authkeylen,
DMA_TO_DEVICE);
/*
@@ -1080,7 +1079,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
}
/* iv out */
- map_single_talitos_ptr(dev, desc-ptr[6], ivsize, ctx-iv, 0,
+ map_single_talitos_ptr(dev, desc-ptr[6], ivsize, ctx-iv,
DMA_FROM_DEVICE);
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
@@ -1453,7 +1452,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* cipher key */
map_single_talitos_ptr(dev, desc-ptr[2], ctx-keylen,
- (char *)ctx-key, 0, DMA_TO_DEVICE);
+ (char *)ctx-key, DMA_TO_DEVICE);
/*
* cipher in
@@ -1470,7 +1469,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
desc-ptr[4], sg_count);
/* iv out */
- map_single_talitos_ptr(dev, desc-ptr[5], ivsize, ctx-iv, 0,
+ map_single_talitos_ptr(dev, desc-ptr[5], ivsize, ctx-iv,
DMA_FROM_DEVICE);
/* last DWORD empty */
@@ -1595,7 +1594,7 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
if (!req_ctx-first || req_ctx-swinit) {
map_single_talitos_ptr(dev, desc-ptr[1],
req_ctx-hw_context_size,
- (char *)req_ctx-hw_context, 0,
+ (char *)req_ctx-hw_context,
DMA_TO_DEVICE);
req_ctx-swinit = 0;
} else {
@@ -1607,7 +1606,7 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
/* HMAC key */
if (ctx-keylen)
map_single_talitos_ptr(dev, desc-ptr[2], ctx-keylen,
- (char *)ctx-key, 0, DMA_TO_DEVICE);
+ (char *)ctx-key, DMA_TO_DEVICE);
else
desc-ptr[2] = zero_entry;
@@ -1624,11 +1623,11 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
if (req_ctx-last)
map_single_talitos_ptr(dev, desc-ptr[5],
crypto_ahash_digestsize(tfm),
- areq-result, 0, DMA_FROM_DEVICE);
+ areq-result, DMA_FROM_DEVICE);
else
map_single_talitos_ptr(dev, desc-ptr[5],
req_ctx-hw_context_size,
- req_ctx-hw_context, 0, DMA_FROM_DEVICE);
+ req_ctx-hw_context, DMA_FROM_DEVICE);
/* last DWORD empty */
desc-ptr[6] = zero_entry;
--
2.1.0
--
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 v3 06/17] crypto: talitos - helper function for ptr len
This patch adds a helper function for reads and writes of the len
param of the talitos descriptor. This will help implement
SEC1 later.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 81e5636..bca6ded 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -61,6 +61,16 @@ static void to_talitos_ptr(struct talitos_ptr *ptr,
dma_addr_t dma_addr)
ptr-eptr = upper_32_bits(dma_addr);
}
+static void to_talitos_ptr_len(struct talitos_ptr *ptr, unsigned short len)
+{
+ ptr-len = cpu_to_be16(len);
+}
+
+static unsigned short from_talitos_ptr_len(struct talitos_ptr *ptr)
+{
+ return be16_to_cpu(ptr-len);
+}
+
static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr)
{
ptr-j_extent = 0;
@@ -76,7 +86,7 @@ static void map_single_talitos_ptr(struct device *dev,
{
dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
- ptr-len = cpu_to_be16(len);
+ to_talitos_ptr_len(ptr, len);
to_talitos_ptr(ptr, dma_addr);
to_talitos_ptr_extent_clear(ptr);
}
@@ -89,7 +99,7 @@ static void unmap_single_talitos_ptr(struct device *dev,
enum dma_data_direction dir)
{
dma_unmap_single(dev, be32_to_cpu(ptr-ptr),
-be16_to_cpu(ptr-len), dir);
+from_talitos_ptr_len(ptr), dir);
}
static int reset_channel(struct device *dev, int ch)
@@ -1375,7 +1385,7 @@ int map_sg_in_talitos_ptr(struct device *dev, struct
scatterlist *src,
{
int sg_count;
- ptr-len = cpu_to_be16(len);
+ to_talitos_ptr_len(ptr, len);
to_talitos_ptr_extent_clear(ptr);
sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
@@ -1405,7 +1415,7 @@ void map_sg_out_talitos_ptr(struct device *dev, struct
scatterlist *dst,
enum dma_data_direction dir,
struct talitos_ptr *ptr, int sg_count)
{
- ptr-len = cpu_to_be16(len);
+ to_talitos_ptr_len(ptr, len);
to_talitos_ptr_extent_clear(ptr);
if (dir != DMA_NONE)
@@ -1447,7 +1457,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
- desc-ptr[1].len = cpu_to_be16(ivsize);
+ to_talitos_ptr_len(desc-ptr[1], ivsize);
to_talitos_ptr_extent_clear(desc-ptr[1]);
/* cipher key */
@@ -1539,11 +1549,11 @@ static void common_nonsnoop_hash_unmap(struct device
*dev,
unmap_sg_talitos_ptr(dev, req_ctx-psrc, NULL, 0, edesc);
/* When using hashctx-in, must unmap it. */
- if (edesc-desc.ptr[1].len)
+ if (from_talitos_ptr_len(edesc-desc.ptr[1]))
unmap_single_talitos_ptr(dev, edesc-desc.ptr[1],
DMA_TO_DEVICE);
- if (edesc-desc.ptr[2].len)
+ if (from_talitos_ptr_len(edesc-desc.ptr[2]))
unmap_single_talitos_ptr(dev, edesc-desc.ptr[2],
DMA_TO_DEVICE);
--
2.1.0
--
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 v3 04/17] crypto: talitos - Add a helper function to clear j_extent field
j_extent field is specific to SEC2 so we add a helper function to clear it
so that SEC1 can redefine that function as nop
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index fca0aed..c93f79b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -61,6 +61,11 @@ static void to_talitos_ptr(struct talitos_ptr *ptr,
dma_addr_t dma_addr)
ptr-eptr = upper_32_bits(dma_addr);
}
+static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr)
+{
+ ptr-j_extent = 0;
+}
+
/*
* map virtual single (contiguous) pointer to h/w descriptor pointer
*/
@@ -1372,7 +1377,7 @@ int map_sg_in_talitos_ptr(struct device *dev, struct
scatterlist *src,
int sg_count;
ptr-len = cpu_to_be16(len);
- ptr-j_extent = 0;
+ to_talitos_ptr_extent_clear(ptr);
sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
edesc-src_chained);
@@ -1402,7 +1407,7 @@ void map_sg_out_talitos_ptr(struct device *dev, struct
scatterlist *dst,
struct talitos_ptr *ptr, int sg_count)
{
ptr-len = cpu_to_be16(len);
- ptr-j_extent = 0;
+ to_talitos_ptr_extent_clear(ptr);
if (dir != DMA_NONE)
sg_count = talitos_map_sg(dev, dst, edesc-dst_nents ? : 1,
@@ -1444,7 +1449,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
desc-ptr[1].len = cpu_to_be16(ivsize);
- desc-ptr[1].j_extent = 0;
+ to_talitos_ptr_extent_clear(desc-ptr[1]);
/* cipher key */
map_single_talitos_ptr(dev, desc-ptr[2], ctx-keylen,
--
2.1.0
--
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 v3 04/17] crypto: talitos - Add a helper function to clear j_extent field
j_extent field is specific to SEC2 so we add a helper function to clear it
so that SEC1 can redefine that function as nop
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index fca0aed..c93f79b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -61,6 +61,11 @@ static void to_talitos_ptr(struct talitos_ptr *ptr,
dma_addr_t dma_addr)
ptr-eptr = upper_32_bits(dma_addr);
}
+static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr)
+{
+ ptr-j_extent = 0;
+}
+
/*
* map virtual single (contiguous) pointer to h/w descriptor pointer
*/
@@ -1372,7 +1377,7 @@ int map_sg_in_talitos_ptr(struct device *dev, struct
scatterlist *src,
int sg_count;
ptr-len = cpu_to_be16(len);
- ptr-j_extent = 0;
+ to_talitos_ptr_extent_clear(ptr);
sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
edesc-src_chained);
@@ -1402,7 +1407,7 @@ void map_sg_out_talitos_ptr(struct device *dev, struct
scatterlist *dst,
struct talitos_ptr *ptr, int sg_count)
{
ptr-len = cpu_to_be16(len);
- ptr-j_extent = 0;
+ to_talitos_ptr_extent_clear(ptr);
if (dir != DMA_NONE)
sg_count = talitos_map_sg(dev, dst, edesc-dst_nents ? : 1,
@@ -1444,7 +1449,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
desc-ptr[1].len = cpu_to_be16(ivsize);
- desc-ptr[1].j_extent = 0;
+ to_talitos_ptr_extent_clear(desc-ptr[1]);
/* cipher key */
map_single_talitos_ptr(dev, desc-ptr[2], ctx-keylen,
--
2.1.0
--
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 v3 12/17] crypto: talitos - base address for Execution Units
SEC 1.0, 1.2 and 2.x+ have different EU base addresses, so we need to
define pointers for each EU in the driver private data structure.
The proper address is set by the probe function depending on the
SEC type, in order to provide access to the proper address.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 83
drivers/crypto/talitos.h | 72 +
2 files changed, 100 insertions(+), 55 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index e6ea651..6d77699 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -208,7 +208,7 @@ static int init_device(struct device *dev)
/* disable integrity check error interrupts (use writeback instead) */
if (priv-features TALITOS_FTR_HW_AUTH_CHECK)
- setbits32(priv-reg + TALITOS_MDEUICR_LO,
+ setbits32(priv-reg_mdeu + TALITOS_EUICR_LO,
TALITOS_MDEUICR_LO_ICE);
return 0;
@@ -424,44 +424,44 @@ static void report_eu_error(struct device *dev, int ch,
u32 desc_hdr)
switch (desc_hdr DESC_HDR_SEL0_MASK) {
case DESC_HDR_SEL0_AFEU:
dev_err(dev, AFEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_AFEUISR),
- in_be32(priv-reg + TALITOS_AFEUISR_LO));
+ in_be32(priv-reg_afeu + TALITOS_EUISR),
+ in_be32(priv-reg_afeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_DEU:
dev_err(dev, DEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_DEUISR),
- in_be32(priv-reg + TALITOS_DEUISR_LO));
+ in_be32(priv-reg_deu + TALITOS_EUISR),
+ in_be32(priv-reg_deu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_MDEUA:
case DESC_HDR_SEL0_MDEUB:
dev_err(dev, MDEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_MDEUISR),
- in_be32(priv-reg + TALITOS_MDEUISR_LO));
+ in_be32(priv-reg_mdeu + TALITOS_EUISR),
+ in_be32(priv-reg_mdeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_RNG:
dev_err(dev, RNGUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_RNGUISR),
- in_be32(priv-reg + TALITOS_RNGUISR_LO));
+ in_be32(priv-reg_rngu + TALITOS_ISR),
+ in_be32(priv-reg_rngu + TALITOS_ISR_LO));
break;
case DESC_HDR_SEL0_PKEU:
dev_err(dev, PKEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_PKEUISR),
- in_be32(priv-reg + TALITOS_PKEUISR_LO));
+ in_be32(priv-reg_pkeu + TALITOS_EUISR),
+ in_be32(priv-reg_pkeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_AESU:
dev_err(dev, AESUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_AESUISR),
- in_be32(priv-reg + TALITOS_AESUISR_LO));
+ in_be32(priv-reg_aesu + TALITOS_EUISR),
+ in_be32(priv-reg_aesu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_CRCU:
dev_err(dev, CRCUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_CRCUISR),
- in_be32(priv-reg + TALITOS_CRCUISR_LO));
+ in_be32(priv-reg_crcu + TALITOS_EUISR),
+ in_be32(priv-reg_crcu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_KEU:
dev_err(dev, KEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_KEUISR),
- in_be32(priv-reg + TALITOS_KEUISR_LO));
+ in_be32(priv-reg_pkeu + TALITOS_EUISR),
+ in_be32(priv-reg_pkeu + TALITOS_EUISR_LO));
break;
}
@@ -469,13 +469,13 @@ static void report_eu_error(struct device *dev, int ch,
u32 desc_hdr)
case DESC_HDR_SEL1_MDEUA:
case DESC_HDR_SEL1_MDEUB:
dev_err(dev, MDEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_MDEUISR),
- in_be32(priv-reg + TALITOS_MDEUISR_LO));
+ in_be32(priv-reg_mdeu + TALITOS_EUISR),
+ in_be32(priv-reg_mdeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL1_CRCU:
dev_err(dev, CRCUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_CRCUISR),
- in_be32(priv-reg + TALITOS_CRCUISR_LO));
+ in_be32(priv-reg_crcu + TALITOS_EUISR),
+ in_be32(priv-reg_crcu +
[PATCH v3 01/17] crypto: talitos - Use zero entry to init descriptors ptrs to zero
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 857414a..7bf1b2b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1373,9 +1373,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
int sg_count, ret;
/* first DWORD empty */
- desc-ptr[0].len = 0;
- to_talitos_ptr(desc-ptr[0], 0);
- desc-ptr[0].j_extent = 0;
+ desc-ptr[0] = zero_entry;
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
@@ -1445,9 +1443,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
DMA_FROM_DEVICE);
/* last DWORD empty */
- desc-ptr[6].len = 0;
- to_talitos_ptr(desc-ptr[6], 0);
- desc-ptr[6].j_extent = 0;
+ desc-ptr[6] = zero_entry;
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
--
2.1.0
--
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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote: Hi Gregory, On Fri, 17 Apr 2015 15:01:01 +0200 Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. I like the idea :-). Not really, how do you know which device is going to be probed? For that matter, it's pretty much random, and you have no control over it. Why not just have a choice option, and select which one you want to enable? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH v3 05/17] crypto: talitos - remove param 'extent' in map_single_talitos_ptr()
map_single_talitos_ptr() is always called with extent == 0, so lets remove this
unused parameter
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c93f79b..81e5636 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -72,14 +72,13 @@ static void to_talitos_ptr_extent_clear(struct talitos_ptr
*ptr)
static void map_single_talitos_ptr(struct device *dev,
struct talitos_ptr *ptr,
unsigned short len, void *data,
- unsigned char extent,
enum dma_data_direction dir)
{
dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
ptr-len = cpu_to_be16(len);
to_talitos_ptr(ptr, dma_addr);
- ptr-j_extent = extent;
+ to_talitos_ptr_extent_clear(ptr);
}
/*
@@ -958,7 +957,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
/* hmac key */
map_single_talitos_ptr(dev, desc-ptr[0], ctx-authkeylen, ctx-key,
- 0, DMA_TO_DEVICE);
+ DMA_TO_DEVICE);
/* hmac data */
desc-ptr[1].len = cpu_to_be16(areq-assoclen + ivsize);
@@ -1002,7 +1001,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
/* cipher key */
map_single_talitos_ptr(dev, desc-ptr[3], ctx-enckeylen,
- (char *)ctx-key + ctx-authkeylen, 0,
+ (char *)ctx-key + ctx-authkeylen,
DMA_TO_DEVICE);
/*
@@ -1080,7 +1079,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
}
/* iv out */
- map_single_talitos_ptr(dev, desc-ptr[6], ivsize, ctx-iv, 0,
+ map_single_talitos_ptr(dev, desc-ptr[6], ivsize, ctx-iv,
DMA_FROM_DEVICE);
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
@@ -1453,7 +1452,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* cipher key */
map_single_talitos_ptr(dev, desc-ptr[2], ctx-keylen,
- (char *)ctx-key, 0, DMA_TO_DEVICE);
+ (char *)ctx-key, DMA_TO_DEVICE);
/*
* cipher in
@@ -1470,7 +1469,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
desc-ptr[4], sg_count);
/* iv out */
- map_single_talitos_ptr(dev, desc-ptr[5], ivsize, ctx-iv, 0,
+ map_single_talitos_ptr(dev, desc-ptr[5], ivsize, ctx-iv,
DMA_FROM_DEVICE);
/* last DWORD empty */
@@ -1595,7 +1594,7 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
if (!req_ctx-first || req_ctx-swinit) {
map_single_talitos_ptr(dev, desc-ptr[1],
req_ctx-hw_context_size,
- (char *)req_ctx-hw_context, 0,
+ (char *)req_ctx-hw_context,
DMA_TO_DEVICE);
req_ctx-swinit = 0;
} else {
@@ -1607,7 +1606,7 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
/* HMAC key */
if (ctx-keylen)
map_single_talitos_ptr(dev, desc-ptr[2], ctx-keylen,
- (char *)ctx-key, 0, DMA_TO_DEVICE);
+ (char *)ctx-key, DMA_TO_DEVICE);
else
desc-ptr[2] = zero_entry;
@@ -1624,11 +1623,11 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
if (req_ctx-last)
map_single_talitos_ptr(dev, desc-ptr[5],
crypto_ahash_digestsize(tfm),
- areq-result, 0, DMA_FROM_DEVICE);
+ areq-result, DMA_FROM_DEVICE);
else
map_single_talitos_ptr(dev, desc-ptr[5],
req_ctx-hw_context_size,
- req_ctx-hw_context, 0, DMA_FROM_DEVICE);
+ req_ctx-hw_context, DMA_FROM_DEVICE);
/* last DWORD empty */
desc-ptr[6] = zero_entry;
--
2.1.0
--
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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hi Maxime, On 17/04/2015 16:32, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote: Hi Gregory, On Fri, 17 Apr 2015 15:01:01 +0200 Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. I like the idea :-). Not really, how do you know which device is going to be probed? For that matter, it's pretty much random, and you have no control over it. Why not just have a choice option, and select which one you want to enable? Because you can't prevent an user to build a module, then modifying the configuration and building the other module. So even if there is a choice at build time, and I think that it is something expected for the v2, we still need preventing having the both drivers trying accessing the same hardware in the same time. Thanks, Gregory Maxime -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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 v3 06/17] crypto: talitos - helper function for ptr len
This patch adds a helper function for reads and writes of the len
param of the talitos descriptor. This will help implement
SEC1 later.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 81e5636..bca6ded 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -61,6 +61,16 @@ static void to_talitos_ptr(struct talitos_ptr *ptr,
dma_addr_t dma_addr)
ptr-eptr = upper_32_bits(dma_addr);
}
+static void to_talitos_ptr_len(struct talitos_ptr *ptr, unsigned short len)
+{
+ ptr-len = cpu_to_be16(len);
+}
+
+static unsigned short from_talitos_ptr_len(struct talitos_ptr *ptr)
+{
+ return be16_to_cpu(ptr-len);
+}
+
static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr)
{
ptr-j_extent = 0;
@@ -76,7 +86,7 @@ static void map_single_talitos_ptr(struct device *dev,
{
dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
- ptr-len = cpu_to_be16(len);
+ to_talitos_ptr_len(ptr, len);
to_talitos_ptr(ptr, dma_addr);
to_talitos_ptr_extent_clear(ptr);
}
@@ -89,7 +99,7 @@ static void unmap_single_talitos_ptr(struct device *dev,
enum dma_data_direction dir)
{
dma_unmap_single(dev, be32_to_cpu(ptr-ptr),
-be16_to_cpu(ptr-len), dir);
+from_talitos_ptr_len(ptr), dir);
}
static int reset_channel(struct device *dev, int ch)
@@ -1375,7 +1385,7 @@ int map_sg_in_talitos_ptr(struct device *dev, struct
scatterlist *src,
{
int sg_count;
- ptr-len = cpu_to_be16(len);
+ to_talitos_ptr_len(ptr, len);
to_talitos_ptr_extent_clear(ptr);
sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
@@ -1405,7 +1415,7 @@ void map_sg_out_talitos_ptr(struct device *dev, struct
scatterlist *dst,
enum dma_data_direction dir,
struct talitos_ptr *ptr, int sg_count)
{
- ptr-len = cpu_to_be16(len);
+ to_talitos_ptr_len(ptr, len);
to_talitos_ptr_extent_clear(ptr);
if (dir != DMA_NONE)
@@ -1447,7 +1457,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
- desc-ptr[1].len = cpu_to_be16(ivsize);
+ to_talitos_ptr_len(desc-ptr[1], ivsize);
to_talitos_ptr_extent_clear(desc-ptr[1]);
/* cipher key */
@@ -1539,11 +1549,11 @@ static void common_nonsnoop_hash_unmap(struct device
*dev,
unmap_sg_talitos_ptr(dev, req_ctx-psrc, NULL, 0, edesc);
/* When using hashctx-in, must unmap it. */
- if (edesc-desc.ptr[1].len)
+ if (from_talitos_ptr_len(edesc-desc.ptr[1]))
unmap_single_talitos_ptr(dev, edesc-desc.ptr[1],
DMA_TO_DEVICE);
- if (edesc-desc.ptr[2].len)
+ if (from_talitos_ptr_len(edesc-desc.ptr[2]))
unmap_single_talitos_ptr(dev, edesc-desc.ptr[2],
DMA_TO_DEVICE);
--
2.1.0
--
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 v3 01/17] crypto: talitos - Use zero entry to init descriptors ptrs to zero
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 857414a..7bf1b2b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1373,9 +1373,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
int sg_count, ret;
/* first DWORD empty */
- desc-ptr[0].len = 0;
- to_talitos_ptr(desc-ptr[0], 0);
- desc-ptr[0].j_extent = 0;
+ desc-ptr[0] = zero_entry;
/* cipher iv */
to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
@@ -1445,9 +1443,7 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
DMA_FROM_DEVICE);
/* last DWORD empty */
- desc-ptr[6].len = 0;
- to_talitos_ptr(desc-ptr[6], 0);
- desc-ptr[6].j_extent = 0;
+ desc-ptr[6] = zero_entry;
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
--
2.1.0
--
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
Re: DRBG seeding
Am Freitag, 17. April 2015, 21:11:37 schrieb Herbert Xu: Hi Herbert, On Fri, Apr 17, 2015 at 02:48:51PM +0200, Stephan Mueller wrote: Do you really think that this is possible? If the DRBG becomes the stdrng, you would imply that those callers (e.g. IPSEC) may suffer from a long block (and with long I mean not just seconds, but minutes). It's only 49 bytes for every 64K so I think it's reasonable. Just an FYI on a test I did once: on a headless PPC (POWER6), we drained /dev/random (simply do a cat /dev/random). Then it took more than 20 hours(!) to get 48 bytes to seed OpenSSL from /dev/random. This test was done on some 2.6.32 kernel. That issue should be better now considering that interrupts are used as noise source by /dev/random. Furthermore, it gets worse again considering that there is work underway to disable SSDs to feed /dev/random. Thus, on a server that is headless but has SSDs we only have interrupts feeding into /dev/random. Thus, getting a full seed of 384 bits is minutes on a headless system will definitely be a challenge in a worst case. The only reason someone would use this is to comply with the standard and this is what the standard requires so I don't see how we can do anything else. I do not see a definite quality requirement of the seed source in SP800-90A. In user space, FIPS validations happily used /dev/urandom where NIST has no concern. Currently, there is a draft interpretation that tightens the issue around /dev/urandom significantly. Therefore, looking into the issue is definitely important. But still, blocking the DRBG right from the start until we have data from /dev/random does not seem helpful either. Furthermore, I fail to see the difference between the current default stdrng (krng -- which is just get_random_bytes in disguise). Thus, the current situation with the DRBG seeding is not different from the non-DRBG use case. The difference is that krng doesn't have to satisfy any standard. Cheers, -- Ciao Stephan -- 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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hey Boris, On Fri, Apr 17, 2015 at 10:39:46AM +0200, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? I'm kinda wrapped up with dayjob stuff atm... But I'd look at the wireless drivers. eg b43, b43legacy, brcm80211. There are devices they overlap for. So, they need to deconflict in some way. thx, Jason. -- 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 v3 09/17] crypto: talitos - Add a feature to tag SEC1
We add a new feature in the features field, to mark compatible
fsl,sec1.0
We also define a helper function called has_ftr_sec1() to help
functions quickly determine if they are running on SEC1 or SEC2+.
When only SEC1 or SEC2 is compiled in, has_ftr_sec1() return
trivial corresponding value. If both are compiled in, feature
field is checked.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 3 +++
drivers/crypto/talitos.h | 17 +
2 files changed, 20 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index bca6ded..db95023 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2709,6 +2709,9 @@ static int talitos_probe(struct platform_device *ofdev)
TALITOS_FTR_SHA224_HWINIT |
TALITOS_FTR_HMAC_OK;
+ if (of_device_is_compatible(np, fsl,sec1.0))
+ priv-features |= TALITOS_FTR_SEC1;
+
priv-chan = kzalloc(sizeof(struct talitos_channel) *
priv-num_channels, GFP_KERNEL);
if (!priv-chan) {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index f078da1..b0bdb4e 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -156,6 +156,23 @@ extern int talitos_submit(struct device *dev, int ch,
struct talitos_desc *desc,
#define TALITOS_FTR_HW_AUTH_CHECK 0x0002
#define TALITOS_FTR_SHA224_HWINIT 0x0004
#define TALITOS_FTR_HMAC_OK 0x0008
+#define TALITOS_FTR_SEC1 0x0010
+
+/*
+ * If both CONFIG_CRYPTO_DEV_TALITOS1 and CONFIG_CRYPTO_DEV_TALITOS2 are
+ * defined, we check the features which are set according to the device tree.
+ * Otherwise, we answer true or false directly
+ */
+static inline bool has_ftr_sec1(struct talitos_private *priv)
+{
+#if defined(CONFIG_CRYPTO_DEV_TALITOS1) defined(CONFIG_CRYPTO_DEV_TALITOS2)
+ return priv-features TALITOS_FTR_SEC1 ? true : false;
+#elif defined(CONFIG_CRYPTO_DEV_TALITOS1)
+ return true;
+#else
+ return false;
+#endif
+}
/*
* TALITOS_xxx_LO addresses point to the low data bits (32-63) of the register
--
2.1.0
--
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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
Hi Gregory, On Fri, 17 Apr 2015 15:01:01 +0200 Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. I like the idea :-). However, the old driver doesn't try to reserve the region, it directly uses an ioremap(). So if the new driver is loaded first, then the old one will manage to be loaded too. I think that just adding a request_region()/release_region() (or converting the ioremap in a devm_ioremap_resource() in the old driver would be enough. Absolutely. Unless someone is opposed to this solution I think I'll choose this solution. Thanks, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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 v3 08/17] crypto: talitos - add sub-choice in talitos CONFIG for SEC1
This patch adds a CONFIG option to select SEC1, SEC2+ or both. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- drivers/crypto/Kconfig | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 800bf41..8a76a01 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -222,6 +222,24 @@ config CRYPTO_DEV_TALITOS To compile this driver as a module, choose M here: the module will be called talitos. +config CRYPTO_DEV_TALITOS1 + bool SEC1 (SEC 1.0 and SEC Lite 1.2) + depends on CRYPTO_DEV_TALITOS + depends on PPC_8xx || PPC_82xx + default y + help + Say 'Y' here to use the Freescale Security Engine (SEC) version 1.0 + found on MPC82xx or the Freescale Security Engine (SEC Lite) + version 1.2 found on MPC8xx + +config CRYPTO_DEV_TALITOS2 + bool SEC2+ (SEC version 2.0 or upper) + depends on CRYPTO_DEV_TALITOS + default y if !PPC_8xx + help + Say 'Y' here to use the Freescale Security Engine (SEC) + version 2 and following as found on MPC83xx, MPC85xx, etc ... + config CRYPTO_DEV_IXP4XX tristate Driver for IXP4xx crypto hardware acceleration depends on ARCH_IXP4XX IXP4XX_QMGR IXP4XX_NPE -- 2.1.0 -- 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 v3 17/17] crypto: talitos - Update DT bindings with SEC1
This patch updates the documentation by including SEC1 into SEC2/3 doc Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt index 38988ef..f0d926b 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt @@ -1,9 +1,11 @@ -Freescale SoC SEC Security Engines versions 2.x-3.x +Freescale SoC SEC Security Engines versions 1.x-2.x-3.x Required properties: - compatible : Should contain entries for this and backward compatible - SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0 + SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0 (SEC2/3) + e.g., fsl,sec1.2, fsl,sec1.0 (SEC1) +warning: SEC1 and SEC2 are mutually exclusive - reg : Offset and length of the register set for the device - interrupts : the SEC's interrupt number - fsl,num-channels : An integer representing the number of channels -- 2.1.0 -- 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 v3 16/17] crypto: talitos - Add fsl,sec1.0 compatible
We add a specific compatible for SEC1, to handle the differences
between SEC1 and SEC2+
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index f1406d7b..c04074d 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -3086,9 +3086,16 @@ err_out:
}
static const struct of_device_id talitos_match[] = {
+#ifdef CONFIG_CRYPTO_DEV_TALITOS1
+ {
+ .compatible = fsl,sec1.0,
+ },
+#endif
+#ifdef CONFIG_CRYPTO_DEV_TALITOS2
{
.compatible = fsl,sec2.0,
},
+#endif
{},
};
MODULE_DEVICE_TABLE(of, talitos_match);
--
2.1.0
--
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 v3 17/17] crypto: talitos - Update DT bindings with SEC1
This patch updates the documentation by including SEC1 into SEC2/3 doc Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt index 38988ef..f0d926b 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt @@ -1,9 +1,11 @@ -Freescale SoC SEC Security Engines versions 2.x-3.x +Freescale SoC SEC Security Engines versions 1.x-2.x-3.x Required properties: - compatible : Should contain entries for this and backward compatible - SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0 + SEC versions, high to low, e.g., fsl,sec2.1, fsl,sec2.0 (SEC2/3) + e.g., fsl,sec1.2, fsl,sec1.0 (SEC1) +warning: SEC1 and SEC2 are mutually exclusive - reg : Offset and length of the register set for the device - interrupts : the SEC's interrupt number - fsl,num-channels : An integer representing the number of channels -- 2.1.0 -- 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 v3 11/17] crypto: talitos - adaptation of talitos_submit() for SEC1
SEC1 descriptor is a bit different to SEC2+ descriptor.
talitos_submit() will have to copy hdr field into hdr1 field and
send the descriptor starting at hdr1 up to next_desc.
For SEC2, it remains unchanged and next_desc is just ignored.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 23 +++
drivers/crypto/talitos.h | 2 ++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 678b528..e6ea651 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -236,6 +236,7 @@ int talitos_submit(struct device *dev, int ch, struct
talitos_desc *desc,
struct talitos_request *request;
unsigned long flags;
int head;
+ bool is_sec1 = has_ftr_sec1(priv);
spin_lock_irqsave(priv-chan[ch].head_lock, flags);
@@ -249,8 +250,17 @@ int talitos_submit(struct device *dev, int ch, struct
talitos_desc *desc,
request = priv-chan[ch].fifo[head];
/* map descriptor and save caller data */
- request-dma_desc = dma_map_single(dev, desc, sizeof(*desc),
- DMA_BIDIRECTIONAL);
+ if (is_sec1) {
+ desc-hdr1 = desc-hdr;
+ desc-next_desc = 0;
+ request-dma_desc = dma_map_single(dev, desc-hdr1,
+ TALITOS_DESC_SIZE,
+ DMA_BIDIRECTIONAL);
+ } else {
+ request-dma_desc = dma_map_single(dev, desc,
+ TALITOS_DESC_SIZE,
+ DMA_BIDIRECTIONAL);
+ }
request-callback = callback;
request-context = context;
@@ -282,16 +292,21 @@ static void flush_channel(struct device *dev, int ch, int
error, int reset_ch)
struct talitos_request *request, saved_req;
unsigned long flags;
int tail, status;
+ bool is_sec1 = has_ftr_sec1(priv);
spin_lock_irqsave(priv-chan[ch].tail_lock, flags);
tail = priv-chan[ch].tail;
while (priv-chan[ch].fifo[tail].desc) {
+ __be32 hdr;
+
request = priv-chan[ch].fifo[tail];
/* descriptors with their done bits set don't get the error */
rmb();
- if ((request-desc-hdr DESC_HDR_DONE) == DESC_HDR_DONE)
+ hdr = is_sec1 ? request-desc-hdr1 : request-desc-hdr;
+
+ if ((hdr DESC_HDR_DONE) == DESC_HDR_DONE)
status = 0;
else
if (!error)
@@ -300,7 +315,7 @@ static void flush_channel(struct device *dev, int ch, int
error, int reset_ch)
status = error;
dma_unmap_single(dev, request-dma_desc,
-sizeof(struct talitos_desc),
+TALITOS_DESC_SIZE,
DMA_BIDIRECTIONAL);
/* copy entries so we can call callback outside lock */
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index b0bdb4e..f827c04 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -69,6 +69,8 @@ struct talitos_desc {
__be32 next_desc; /* next descriptor (SEC1) */
};
+#define TALITOS_DESC_SIZE (sizeof(struct talitos_desc) - sizeof(__be32))
+
/**
* talitos_request - descriptor submission request
* @desc: descriptor pointer (kernel virtual)
--
2.1.0
--
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 v3 10/17] crypto: talitos - fill in talitos descriptor iaw SEC1 or SEC2+
talitos descriptor is slightly different for SEC1 and SEC2+, so
lets the helper function that fills the descriptor take into account
the type of SEC.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 105 ++-
1 file changed, 67 insertions(+), 38 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index db95023..678b528 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -55,25 +55,38 @@
#include talitos.h
-static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr)
+static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr,
+ bool is_sec1)
{
ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
- ptr-eptr = upper_32_bits(dma_addr);
+ if (!is_sec1)
+ ptr-eptr = upper_32_bits(dma_addr);
}
-static void to_talitos_ptr_len(struct talitos_ptr *ptr, unsigned short len)
+static void to_talitos_ptr_len(struct talitos_ptr *ptr, unsigned short len,
+ bool is_sec1)
{
- ptr-len = cpu_to_be16(len);
+ if (is_sec1) {
+ ptr-res = 0;
+ ptr-len1 = cpu_to_be16(len);
+ } else {
+ ptr-len = cpu_to_be16(len);
+ }
}
-static unsigned short from_talitos_ptr_len(struct talitos_ptr *ptr)
+static unsigned short from_talitos_ptr_len(struct talitos_ptr *ptr,
+ bool is_sec1)
{
- return be16_to_cpu(ptr-len);
+ if (is_sec1)
+ return be16_to_cpu(ptr-len1);
+ else
+ return be16_to_cpu(ptr-len);
}
-static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr)
+static void to_talitos_ptr_extent_clear(struct talitos_ptr *ptr, bool is_sec1)
{
- ptr-j_extent = 0;
+ if (!is_sec1)
+ ptr-j_extent = 0;
}
/*
@@ -85,10 +98,12 @@ static void map_single_talitos_ptr(struct device *dev,
enum dma_data_direction dir)
{
dma_addr_t dma_addr = dma_map_single(dev, data, len, dir);
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
- to_talitos_ptr_len(ptr, len);
- to_talitos_ptr(ptr, dma_addr);
- to_talitos_ptr_extent_clear(ptr);
+ to_talitos_ptr_len(ptr, len, is_sec1);
+ to_talitos_ptr(ptr, dma_addr, is_sec1);
+ to_talitos_ptr_extent_clear(ptr, is_sec1);
}
/*
@@ -98,8 +113,11 @@ static void unmap_single_talitos_ptr(struct device *dev,
struct talitos_ptr *ptr,
enum dma_data_direction dir)
{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
+
dma_unmap_single(dev, be32_to_cpu(ptr-ptr),
-from_talitos_ptr_len(ptr), dir);
+from_talitos_ptr_len(ptr, is_sec1), dir);
}
static int reset_channel(struct device *dev, int ch)
@@ -922,7 +940,7 @@ static int sg_to_link_tbl(struct scatterlist *sg, int
sg_count,
int n_sg = sg_count;
while (n_sg--) {
- to_talitos_ptr(link_tbl_ptr, sg_dma_address(sg));
+ to_talitos_ptr(link_tbl_ptr, sg_dma_address(sg), 0);
link_tbl_ptr-len = cpu_to_be16(sg_dma_len(sg));
link_tbl_ptr-j_extent = 0;
link_tbl_ptr++;
@@ -976,7 +994,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
struct talitos_ptr *tbl_ptr = edesc-link_tbl[tbl_off];
to_talitos_ptr(desc-ptr[1], edesc-dma_link_tbl + tbl_off *
- sizeof(struct talitos_ptr));
+ sizeof(struct talitos_ptr), 0);
desc-ptr[1].j_extent = DESC_PTR_LNKTBL_JUMP;
/* assoc_nents - 1 entries for assoc, 1 for IV */
@@ -987,7 +1005,7 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
tbl_ptr += sg_count - 1;
tbl_ptr-j_extent = 0;
tbl_ptr++;
- to_talitos_ptr(tbl_ptr, edesc-iv_dma);
+ to_talitos_ptr(tbl_ptr, edesc-iv_dma, 0);
tbl_ptr-len = cpu_to_be16(ivsize);
tbl_ptr-j_extent = DESC_PTR_LNKTBL_RETURN;
@@ -996,14 +1014,14 @@ static int ipsec_esp(struct talitos_edesc *edesc, struct
aead_request *areq,
} else {
if (areq-assoclen)
to_talitos_ptr(desc-ptr[1],
- sg_dma_address(areq-assoc));
+ sg_dma_address(areq-assoc), 0);
else
- to_talitos_ptr(desc-ptr[1], edesc-iv_dma);
+ to_talitos_ptr(desc-ptr[1], edesc-iv_dma, 0);
desc-ptr[1].j_extent = 0;
}
/* cipher iv */
-
[PATCH v3 14/17] crypto: talitos - implement scatter/gather copy for SEC1
SEC1 doesn't support scatter/gather, SEC1 doesn't handle link tables.
Therefore, for SEC1 we have to do it by SW. For that, we reserve
space at the end of the extended descriptor, in lieu of the space
reserved for the link tables on SEC2, and we perform sg_copy() when
preparing the descriptors
We also adapt the max buffer size which is only 32k on SEC1 while it
is 64k on SEC2+
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 138 ++-
drivers/crypto/talitos.h | 3 +-
2 files changed, 103 insertions(+), 38 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 1265405..dddf4b3 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -866,9 +866,10 @@ badkey:
* @dst_chained: whether dst is chained or not
* @iv_dma: dma address of iv for checking continuity and link table
* @dma_len: length of dma mapped link_tbl space
- * @dma_link_tbl: bus physical address of link_tbl
+ * @dma_link_tbl: bus physical address of link_tbl/buf
* @desc: h/w descriptor
- * @link_tbl: input and output h/w link tables (if {src,dst}_nents 1)
+ * @link_tbl: input and output h/w link tables (if {src,dst}_nents 1) (SEC2)
+ * @buf: input and output buffeur (if {src,dst}_nents 1) (SEC1)
*
* if decrypting (with authcheck), or either one of src_nents or dst_nents
* is greater than 1, an integrity check value is concatenated to the end
@@ -885,7 +886,10 @@ struct talitos_edesc {
int dma_len;
dma_addr_t dma_link_tbl;
struct talitos_desc desc;
- struct talitos_ptr link_tbl[0];
+ union {
+ struct talitos_ptr link_tbl[0];
+ u8 buf[0];
+ };
};
static int talitos_map_sg(struct device *dev, struct scatterlist *sg,
@@ -1282,8 +1286,11 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
dma_addr_t iv_dma = 0;
gfp_t flags = cryptoflags CRYPTO_TFM_REQ_MAY_SLEEP ? GFP_KERNEL :
GFP_ATOMIC;
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
+ int max_len = is_sec1 ? TALITOS1_MAX_DATA_LEN : TALITOS2_MAX_DATA_LEN;
- if (cryptlen + authsize TALITOS_MAX_DATA_LEN) {
+ if (cryptlen + authsize max_len) {
dev_err(dev, length exceeds h/w max limit\n);
return ERR_PTR(-EINVAL);
}
@@ -1327,8 +1334,12 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
*/
alloc_len = sizeof(struct talitos_edesc);
if (assoc_nents || src_nents || dst_nents) {
- dma_len = (src_nents + dst_nents + 2 + assoc_nents) *
- sizeof(struct talitos_ptr) + authsize;
+ if (is_sec1)
+ dma_len = src_nents ? cryptlen : 0 +
+ dst_nents ? cryptlen : 0;
+ else
+ dma_len = (src_nents + dst_nents + 2 + assoc_nents) *
+ sizeof(struct talitos_ptr) + authsize;
alloc_len += dma_len;
} else {
dma_len = 0;
@@ -1485,7 +1496,27 @@ static void unmap_sg_talitos_ptr(struct device *dev,
struct scatterlist *src,
struct scatterlist *dst, unsigned int len,
struct talitos_edesc *edesc)
{
- talitos_sg_unmap(dev, edesc, src, dst);
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
+
+ if (is_sec1) {
+ if (!edesc-src_nents) {
+ dma_unmap_sg(dev, src, 1,
+dst != src ? DMA_TO_DEVICE
+ : DMA_BIDIRECTIONAL);
+ }
+ if (dst edesc-dst_nents) {
+ dma_sync_single_for_device(dev,
+ edesc-dma_link_tbl + len,
+ len, DMA_FROM_DEVICE);
+ sg_copy_from_buffer(dst, edesc-dst_nents ? : 1,
+ edesc-buf + len, len);
+ } else if (dst dst != src) {
+ dma_unmap_sg(dev, dst, 1, DMA_FROM_DEVICE);
+ }
+ } else {
+ talitos_sg_unmap(dev, edesc, src, dst);
+ }
}
static void common_nonsnoop_unmap(struct device *dev,
@@ -1528,25 +1559,42 @@ int map_sg_in_talitos_ptr(struct device *dev, struct
scatterlist *src,
bool is_sec1 = has_ftr_sec1(priv);
to_talitos_ptr_len(ptr, len, is_sec1);
- to_talitos_ptr_extent_clear(ptr, is_sec1);
- sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
- edesc-src_chained);
+ if (is_sec1) {
+ sg_count = edesc-src_nents ? : 1;
- if (sg_count == 1)
[PATCH v3 09/17] crypto: talitos - Add a feature to tag SEC1
We add a new feature in the features field, to mark compatible
fsl,sec1.0
We also define a helper function called has_ftr_sec1() to help
functions quickly determine if they are running on SEC1 or SEC2+.
When only SEC1 or SEC2 is compiled in, has_ftr_sec1() return
trivial corresponding value. If both are compiled in, feature
field is checked.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 3 +++
drivers/crypto/talitos.h | 17 +
2 files changed, 20 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index bca6ded..db95023 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2709,6 +2709,9 @@ static int talitos_probe(struct platform_device *ofdev)
TALITOS_FTR_SHA224_HWINIT |
TALITOS_FTR_HMAC_OK;
+ if (of_device_is_compatible(np, fsl,sec1.0))
+ priv-features |= TALITOS_FTR_SEC1;
+
priv-chan = kzalloc(sizeof(struct talitos_channel) *
priv-num_channels, GFP_KERNEL);
if (!priv-chan) {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index f078da1..b0bdb4e 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -156,6 +156,23 @@ extern int talitos_submit(struct device *dev, int ch,
struct talitos_desc *desc,
#define TALITOS_FTR_HW_AUTH_CHECK 0x0002
#define TALITOS_FTR_SHA224_HWINIT 0x0004
#define TALITOS_FTR_HMAC_OK 0x0008
+#define TALITOS_FTR_SEC1 0x0010
+
+/*
+ * If both CONFIG_CRYPTO_DEV_TALITOS1 and CONFIG_CRYPTO_DEV_TALITOS2 are
+ * defined, we check the features which are set according to the device tree.
+ * Otherwise, we answer true or false directly
+ */
+static inline bool has_ftr_sec1(struct talitos_private *priv)
+{
+#if defined(CONFIG_CRYPTO_DEV_TALITOS1) defined(CONFIG_CRYPTO_DEV_TALITOS2)
+ return priv-features TALITOS_FTR_SEC1 ? true : false;
+#elif defined(CONFIG_CRYPTO_DEV_TALITOS1)
+ return true;
+#else
+ return false;
+#endif
+}
/*
* TALITOS_xxx_LO addresses point to the low data bits (32-63) of the register
--
2.1.0
--
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 v3 13/17] crypto: talitos - adapt interrupts and reset functions to SEC1
This patch adapts the interrupts handling and reset function for
SEC1. On SEC1, registers are almost similar to SEC2+, but bits
are sometimes located at different places. So we need to define
TALITOS1 and TALITOS2 versions of some fields, and manage according
to whether it is SEC1 or SEC2.
On SEC1, only one interrupt vector is dedicated to the SEC, so only
interrupt_4ch is needed.
On SEC1, interrupts are enabled by clearing related bits in IMR,
while on SEC2, interrupts are enabled by seting the bits in IMR.
SEC1 also performs parity verification in the DES Unit. We have
to disable this feature because the test vectors provided in
the kernel have parity errors.
In reset functions, only SEC2 supports continuation after error.
For SEC1, we have to reset in all cases.
For errors handling, SEC2+ names have been kept, but displayed
text have been amended to reflect exact meaning on SEC1.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 227 +++
drivers/crypto/talitos.h | 39 +---
2 files changed, 199 insertions(+), 67 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 6d77699..1265405 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -124,12 +124,23 @@ static int reset_channel(struct device *dev, int ch)
{
struct talitos_private *priv = dev_get_drvdata(dev);
unsigned int timeout = TALITOS_TIMEOUT;
+ bool is_sec1 = has_ftr_sec1(priv);
- setbits32(priv-chan[ch].reg + TALITOS_CCCR, TALITOS_CCCR_RESET);
+ if (is_sec1) {
+ setbits32(priv-chan[ch].reg + TALITOS_CCCR_LO,
+ TALITOS1_CCCR_LO_RESET);
- while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR) TALITOS_CCCR_RESET)
- --timeout)
- cpu_relax();
+ while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR_LO)
+ TALITOS1_CCCR_LO_RESET) --timeout)
+ cpu_relax();
+ } else {
+ setbits32(priv-chan[ch].reg + TALITOS_CCCR,
+ TALITOS2_CCCR_RESET);
+
+ while ((in_be32(priv-chan[ch].reg + TALITOS_CCCR)
+ TALITOS2_CCCR_RESET) --timeout)
+ cpu_relax();
+ }
if (timeout == 0) {
dev_err(dev, failed to reset channel %d\n, ch);
@@ -152,11 +163,12 @@ static int reset_device(struct device *dev)
{
struct talitos_private *priv = dev_get_drvdata(dev);
unsigned int timeout = TALITOS_TIMEOUT;
- u32 mcr = TALITOS_MCR_SWR;
+ bool is_sec1 = has_ftr_sec1(priv);
+ u32 mcr = is_sec1 ? TALITOS1_MCR_SWR : TALITOS2_MCR_SWR;
setbits32(priv-reg + TALITOS_MCR, mcr);
- while ((in_be32(priv-reg + TALITOS_MCR) TALITOS_MCR_SWR)
+ while ((in_be32(priv-reg + TALITOS_MCR) mcr)
--timeout)
cpu_relax();
@@ -180,6 +192,7 @@ static int init_device(struct device *dev)
{
struct talitos_private *priv = dev_get_drvdata(dev);
int ch, err;
+ bool is_sec1 = has_ftr_sec1(priv);
/*
* Master reset
@@ -203,8 +216,15 @@ static int init_device(struct device *dev)
}
/* enable channel done and error interrupts */
- setbits32(priv-reg + TALITOS_IMR, TALITOS_IMR_INIT);
- setbits32(priv-reg + TALITOS_IMR_LO, TALITOS_IMR_LO_INIT);
+ if (is_sec1) {
+ clrbits32(priv-reg + TALITOS_IMR, TALITOS1_IMR_INIT);
+ clrbits32(priv-reg + TALITOS_IMR_LO, TALITOS1_IMR_LO_INIT);
+ /* disable parity error check in DEU (erroneous? test vect.) */
+ setbits32(priv-reg_deu + TALITOS_EUICR, TALITOS1_DEUICR_KPE);
+ } else {
+ setbits32(priv-reg + TALITOS_IMR, TALITOS2_IMR_INIT);
+ setbits32(priv-reg + TALITOS_IMR_LO, TALITOS2_IMR_LO_INIT);
+ }
/* disable integrity check error interrupts (use writeback instead) */
if (priv-features TALITOS_FTR_HW_AUTH_CHECK)
@@ -349,8 +369,37 @@ static void flush_channel(struct device *dev, int ch, int
error, int reset_ch)
/*
* process completed requests for channels that have done status
*/
-#define DEF_TALITOS_DONE(name, ch_done_mask) \
-static void talitos_done_##name(unsigned long data)\
+#define DEF_TALITOS1_DONE(name, ch_done_mask) \
+static void talitos1_done_##name(unsigned long data) \
+{ \
+ struct device *dev = (struct device *)data; \
+ struct talitos_private *priv = dev_get_drvdata(dev);\
+ unsigned long flags;\
+ \
+ if (ch_done_mask 0x1000)
[PATCH v3 12/17] crypto: talitos - base address for Execution Units
SEC 1.0, 1.2 and 2.x+ have different EU base addresses, so we need to
define pointers for each EU in the driver private data structure.
The proper address is set by the probe function depending on the
SEC type, in order to provide access to the proper address.
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 83
drivers/crypto/talitos.h | 72 +
2 files changed, 100 insertions(+), 55 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index e6ea651..6d77699 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -208,7 +208,7 @@ static int init_device(struct device *dev)
/* disable integrity check error interrupts (use writeback instead) */
if (priv-features TALITOS_FTR_HW_AUTH_CHECK)
- setbits32(priv-reg + TALITOS_MDEUICR_LO,
+ setbits32(priv-reg_mdeu + TALITOS_EUICR_LO,
TALITOS_MDEUICR_LO_ICE);
return 0;
@@ -424,44 +424,44 @@ static void report_eu_error(struct device *dev, int ch,
u32 desc_hdr)
switch (desc_hdr DESC_HDR_SEL0_MASK) {
case DESC_HDR_SEL0_AFEU:
dev_err(dev, AFEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_AFEUISR),
- in_be32(priv-reg + TALITOS_AFEUISR_LO));
+ in_be32(priv-reg_afeu + TALITOS_EUISR),
+ in_be32(priv-reg_afeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_DEU:
dev_err(dev, DEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_DEUISR),
- in_be32(priv-reg + TALITOS_DEUISR_LO));
+ in_be32(priv-reg_deu + TALITOS_EUISR),
+ in_be32(priv-reg_deu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_MDEUA:
case DESC_HDR_SEL0_MDEUB:
dev_err(dev, MDEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_MDEUISR),
- in_be32(priv-reg + TALITOS_MDEUISR_LO));
+ in_be32(priv-reg_mdeu + TALITOS_EUISR),
+ in_be32(priv-reg_mdeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_RNG:
dev_err(dev, RNGUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_RNGUISR),
- in_be32(priv-reg + TALITOS_RNGUISR_LO));
+ in_be32(priv-reg_rngu + TALITOS_ISR),
+ in_be32(priv-reg_rngu + TALITOS_ISR_LO));
break;
case DESC_HDR_SEL0_PKEU:
dev_err(dev, PKEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_PKEUISR),
- in_be32(priv-reg + TALITOS_PKEUISR_LO));
+ in_be32(priv-reg_pkeu + TALITOS_EUISR),
+ in_be32(priv-reg_pkeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_AESU:
dev_err(dev, AESUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_AESUISR),
- in_be32(priv-reg + TALITOS_AESUISR_LO));
+ in_be32(priv-reg_aesu + TALITOS_EUISR),
+ in_be32(priv-reg_aesu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_CRCU:
dev_err(dev, CRCUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_CRCUISR),
- in_be32(priv-reg + TALITOS_CRCUISR_LO));
+ in_be32(priv-reg_crcu + TALITOS_EUISR),
+ in_be32(priv-reg_crcu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL0_KEU:
dev_err(dev, KEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_KEUISR),
- in_be32(priv-reg + TALITOS_KEUISR_LO));
+ in_be32(priv-reg_pkeu + TALITOS_EUISR),
+ in_be32(priv-reg_pkeu + TALITOS_EUISR_LO));
break;
}
@@ -469,13 +469,13 @@ static void report_eu_error(struct device *dev, int ch,
u32 desc_hdr)
case DESC_HDR_SEL1_MDEUA:
case DESC_HDR_SEL1_MDEUB:
dev_err(dev, MDEUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_MDEUISR),
- in_be32(priv-reg + TALITOS_MDEUISR_LO));
+ in_be32(priv-reg_mdeu + TALITOS_EUISR),
+ in_be32(priv-reg_mdeu + TALITOS_EUISR_LO));
break;
case DESC_HDR_SEL1_CRCU:
dev_err(dev, CRCUISR 0x%08x_%08x\n,
- in_be32(priv-reg + TALITOS_CRCUISR),
- in_be32(priv-reg + TALITOS_CRCUISR_LO));
+ in_be32(priv-reg_crcu + TALITOS_EUISR),
+ in_be32(priv-reg_crcu +
[PATCH v3 14/17] crypto: talitos - implement scatter/gather copy for SEC1
SEC1 doesn't support scatter/gather, SEC1 doesn't handle link tables.
Therefore, for SEC1 we have to do it by SW. For that, we reserve
space at the end of the extended descriptor, in lieu of the space
reserved for the link tables on SEC2, and we perform sg_copy() when
preparing the descriptors
We also adapt the max buffer size which is only 32k on SEC1 while it
is 64k on SEC2+
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 138 ++-
drivers/crypto/talitos.h | 3 +-
2 files changed, 103 insertions(+), 38 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 1265405..dddf4b3 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -866,9 +866,10 @@ badkey:
* @dst_chained: whether dst is chained or not
* @iv_dma: dma address of iv for checking continuity and link table
* @dma_len: length of dma mapped link_tbl space
- * @dma_link_tbl: bus physical address of link_tbl
+ * @dma_link_tbl: bus physical address of link_tbl/buf
* @desc: h/w descriptor
- * @link_tbl: input and output h/w link tables (if {src,dst}_nents 1)
+ * @link_tbl: input and output h/w link tables (if {src,dst}_nents 1) (SEC2)
+ * @buf: input and output buffeur (if {src,dst}_nents 1) (SEC1)
*
* if decrypting (with authcheck), or either one of src_nents or dst_nents
* is greater than 1, an integrity check value is concatenated to the end
@@ -885,7 +886,10 @@ struct talitos_edesc {
int dma_len;
dma_addr_t dma_link_tbl;
struct talitos_desc desc;
- struct talitos_ptr link_tbl[0];
+ union {
+ struct talitos_ptr link_tbl[0];
+ u8 buf[0];
+ };
};
static int talitos_map_sg(struct device *dev, struct scatterlist *sg,
@@ -1282,8 +1286,11 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
dma_addr_t iv_dma = 0;
gfp_t flags = cryptoflags CRYPTO_TFM_REQ_MAY_SLEEP ? GFP_KERNEL :
GFP_ATOMIC;
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
+ int max_len = is_sec1 ? TALITOS1_MAX_DATA_LEN : TALITOS2_MAX_DATA_LEN;
- if (cryptlen + authsize TALITOS_MAX_DATA_LEN) {
+ if (cryptlen + authsize max_len) {
dev_err(dev, length exceeds h/w max limit\n);
return ERR_PTR(-EINVAL);
}
@@ -1327,8 +1334,12 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
*/
alloc_len = sizeof(struct talitos_edesc);
if (assoc_nents || src_nents || dst_nents) {
- dma_len = (src_nents + dst_nents + 2 + assoc_nents) *
- sizeof(struct talitos_ptr) + authsize;
+ if (is_sec1)
+ dma_len = src_nents ? cryptlen : 0 +
+ dst_nents ? cryptlen : 0;
+ else
+ dma_len = (src_nents + dst_nents + 2 + assoc_nents) *
+ sizeof(struct talitos_ptr) + authsize;
alloc_len += dma_len;
} else {
dma_len = 0;
@@ -1485,7 +1496,27 @@ static void unmap_sg_talitos_ptr(struct device *dev,
struct scatterlist *src,
struct scatterlist *dst, unsigned int len,
struct talitos_edesc *edesc)
{
- talitos_sg_unmap(dev, edesc, src, dst);
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ bool is_sec1 = has_ftr_sec1(priv);
+
+ if (is_sec1) {
+ if (!edesc-src_nents) {
+ dma_unmap_sg(dev, src, 1,
+dst != src ? DMA_TO_DEVICE
+ : DMA_BIDIRECTIONAL);
+ }
+ if (dst edesc-dst_nents) {
+ dma_sync_single_for_device(dev,
+ edesc-dma_link_tbl + len,
+ len, DMA_FROM_DEVICE);
+ sg_copy_from_buffer(dst, edesc-dst_nents ? : 1,
+ edesc-buf + len, len);
+ } else if (dst dst != src) {
+ dma_unmap_sg(dev, dst, 1, DMA_FROM_DEVICE);
+ }
+ } else {
+ talitos_sg_unmap(dev, edesc, src, dst);
+ }
}
static void common_nonsnoop_unmap(struct device *dev,
@@ -1528,25 +1559,42 @@ int map_sg_in_talitos_ptr(struct device *dev, struct
scatterlist *src,
bool is_sec1 = has_ftr_sec1(priv);
to_talitos_ptr_len(ptr, len, is_sec1);
- to_talitos_ptr_extent_clear(ptr, is_sec1);
- sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
- edesc-src_chained);
+ if (is_sec1) {
+ sg_count = edesc-src_nents ? : 1;
- if (sg_count == 1)
[PATCH v3 08/17] crypto: talitos - add sub-choice in talitos CONFIG for SEC1
This patch adds a CONFIG option to select SEC1, SEC2+ or both. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- drivers/crypto/Kconfig | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 800bf41..8a76a01 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -222,6 +222,24 @@ config CRYPTO_DEV_TALITOS To compile this driver as a module, choose M here: the module will be called talitos. +config CRYPTO_DEV_TALITOS1 + bool SEC1 (SEC 1.0 and SEC Lite 1.2) + depends on CRYPTO_DEV_TALITOS + depends on PPC_8xx || PPC_82xx + default y + help + Say 'Y' here to use the Freescale Security Engine (SEC) version 1.0 + found on MPC82xx or the Freescale Security Engine (SEC Lite) + version 1.2 found on MPC8xx + +config CRYPTO_DEV_TALITOS2 + bool SEC2+ (SEC version 2.0 or upper) + depends on CRYPTO_DEV_TALITOS + default y if !PPC_8xx + help + Say 'Y' here to use the Freescale Security Engine (SEC) + version 2 and following as found on MPC83xx, MPC85xx, etc ... + config CRYPTO_DEV_IXP4XX tristate Driver for IXP4xx crypto hardware acceleration depends on ARCH_IXP4XX IXP4XX_QMGR IXP4XX_NPE -- 2.1.0 -- 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 v3 15/17] crypto: talitos - SEC1 bugs on 0 data hash
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0
data
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dddf4b3..f1406d7b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1797,6 +1797,27 @@ static void ahash_done(struct device *dev,
areq-base.complete(areq-base, err);
}
+/*
+ * SEC1 doesn't like hashing of 0 sized message, so we do the padding
+ * ourself and submit a padded block
+ */
+void talitos_handle_buggy_hash(struct talitos_ctx *ctx,
+ struct talitos_edesc *edesc,
+ struct talitos_ptr *ptr)
+{
+ static u8 padded_hash[64] = {
+ 0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ };
+
+ pr_err_once(Bug in SEC1, padding ourself\n);
+ edesc-desc.hdr = ~DESC_HDR_MODE0_MDEU_PAD;
+ map_single_talitos_ptr(ctx-dev, ptr, sizeof(padded_hash),
+ (char *)padded_hash, DMA_TO_DEVICE);
+}
+
static int common_nonsnoop_hash(struct talitos_edesc *edesc,
struct ahash_request *areq, unsigned int length,
void (*callback) (struct device *dev,
@@ -1857,6 +1878,9 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
/* last DWORD empty */
desc-ptr[6] = zero_entry;
+ if (is_sec1 from_talitos_ptr_len(desc-ptr[3], true) == 0)
+ talitos_handle_buggy_hash(ctx, edesc, desc-ptr[3]);
+
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
common_nonsnoop_hash_unmap(dev, edesc, areq);
--
2.1.0
--
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
Re: [PATCH v3 00/17] crypto: talitos - Add support for SEC1
Oops, this is the first time I use directly the output of git format-patch into sendmail, and it looks like the mails are dated with the commit date, not today's date. I will resend now with today's date. Sorry for the noise. Christophe Le 17/04/2015 15:47, Christophe Leroy a écrit : The purpose of this set of patchs is to add to talitos crypto driver the support for the SEC1 version of the security engine, which is found in mpc885 and mpc8272 processors. v3 is a complete rework of the patchset. Since a kernel can be built with support for both MPC82xx and MPC83xx at the same time, talitos driver shall support both SEC1 and SEC2+ at the same time. Based on cryptodev-2.6 tree Christophe Leroy (17): crypto: talitos - Use zero entry to init descriptors ptrs to zero crypto: talitos - Refactor the sg in/out chain allocation crypto: talitos - talitos_ptr renamed ptr for more lisibility crypto: talitos - Add a helper function to clear j_extent field crypto: talitos - remove param 'extent' in map_single_talitos_ptr() crypto: talitos - helper function for ptr len crypto: talitos - enhanced talitos_desc struct for SEC1 crypto: talitos - add sub-choice in talitos CONFIG for SEC1 crypto: talitos - Add a feature to tag SEC1 crypto: talitos - fill in talitos descriptor iaw SEC1 or SEC2+ crypto: talitos - adaptation of talitos_submit() for SEC1 crypto: talitos - base address for Execution Units crypto: talitos - adapt interrupts and reset functions to SEC1 crypto: talitos - implement scatter/gather copy for SEC1 crypto: talitos - SEC1 bugs on 0 data hash crypto: talitos - Add fsl,sec1.0 compatible crypto: talitos - Update DT bindings with SEC1 .../devicetree/bindings/crypto/fsl-sec2.txt| 6 +- drivers/crypto/Kconfig | 18 + drivers/crypto/talitos.c | 727 +++-- drivers/crypto/talitos.h | 153 +++-- 4 files changed, 644 insertions(+), 260 deletions(-) -- 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 v3 15/17] crypto: talitos - SEC1 bugs on 0 data hash
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0
data
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dddf4b3..f1406d7b 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1797,6 +1797,27 @@ static void ahash_done(struct device *dev,
areq-base.complete(areq-base, err);
}
+/*
+ * SEC1 doesn't like hashing of 0 sized message, so we do the padding
+ * ourself and submit a padded block
+ */
+void talitos_handle_buggy_hash(struct talitos_ctx *ctx,
+ struct talitos_edesc *edesc,
+ struct talitos_ptr *ptr)
+{
+ static u8 padded_hash[64] = {
+ 0x80, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+ };
+
+ pr_err_once(Bug in SEC1, padding ourself\n);
+ edesc-desc.hdr = ~DESC_HDR_MODE0_MDEU_PAD;
+ map_single_talitos_ptr(ctx-dev, ptr, sizeof(padded_hash),
+ (char *)padded_hash, DMA_TO_DEVICE);
+}
+
static int common_nonsnoop_hash(struct talitos_edesc *edesc,
struct ahash_request *areq, unsigned int length,
void (*callback) (struct device *dev,
@@ -1857,6 +1878,9 @@ static int common_nonsnoop_hash(struct talitos_edesc
*edesc,
/* last DWORD empty */
desc-ptr[6] = zero_entry;
+ if (is_sec1 from_talitos_ptr_len(desc-ptr[3], true) == 0)
+ talitos_handle_buggy_hash(ctx, edesc, desc-ptr[3]);
+
ret = talitos_submit(dev, ctx-ch, desc, callback, areq);
if (ret != -EINPROGRESS) {
common_nonsnoop_hash_unmap(dev, edesc, areq);
--
2.1.0
--
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 v3 02/17] crypto: talitos - Refactor the sg in/out chain allocation
This patch refactors the handling of the input and output data that is quite
similar in several functions
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.c | 159 ---
1 file changed, 81 insertions(+), 78 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 7bf1b2b..5a7e345 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1327,16 +1327,23 @@ static int ablkcipher_setkey(struct crypto_ablkcipher
*cipher,
return 0;
}
+static void unmap_sg_talitos_ptr(struct device *dev, struct scatterlist *src,
+struct scatterlist *dst, unsigned int len,
+struct talitos_edesc *edesc)
+{
+ talitos_sg_unmap(dev, edesc, src, dst);
+}
+
static void common_nonsnoop_unmap(struct device *dev,
struct talitos_edesc *edesc,
struct ablkcipher_request *areq)
{
unmap_single_talitos_ptr(dev, edesc-desc.ptr[5], DMA_FROM_DEVICE);
+
+ unmap_sg_talitos_ptr(dev, areq-src, areq-dst, areq-nbytes, edesc);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[2], DMA_TO_DEVICE);
unmap_single_talitos_ptr(dev, edesc-desc.ptr[1], DMA_TO_DEVICE);
- talitos_sg_unmap(dev, edesc, areq-src, areq-dst);
-
if (edesc-dma_len)
dma_unmap_single(dev, edesc-dma_link_tbl, edesc-dma_len,
DMA_BIDIRECTIONAL);
@@ -1358,6 +1365,65 @@ static void ablkcipher_done(struct device *dev,
areq-base.complete(areq-base, err);
}
+int map_sg_in_talitos_ptr(struct device *dev, struct scatterlist *src,
+ unsigned int len, struct talitos_edesc *edesc,
+ enum dma_data_direction dir, struct talitos_ptr *ptr)
+{
+ int sg_count;
+
+ ptr-len = cpu_to_be16(len);
+ ptr-j_extent = 0;
+
+ sg_count = talitos_map_sg(dev, src, edesc-src_nents ? : 1, dir,
+ edesc-src_chained);
+
+ if (sg_count == 1) {
+ to_talitos_ptr(ptr, sg_dma_address(src));
+ } else {
+ sg_count = sg_to_link_tbl(src, sg_count, len,
+ edesc-link_tbl[0]);
+ if (sg_count 1) {
+ to_talitos_ptr(ptr, edesc-dma_link_tbl);
+ ptr-j_extent |= DESC_PTR_LNKTBL_JUMP;
+ dma_sync_single_for_device(dev, edesc-dma_link_tbl,
+ edesc-dma_len,
+ DMA_BIDIRECTIONAL);
+ } else {
+ /* Only one segment now, so no link tbl needed */
+ to_talitos_ptr(ptr, sg_dma_address(src));
+ }
+ }
+ return sg_count;
+}
+
+void map_sg_out_talitos_ptr(struct device *dev, struct scatterlist *dst,
+ unsigned int len, struct talitos_edesc *edesc,
+ enum dma_data_direction dir,
+ struct talitos_ptr *ptr, int sg_count)
+{
+ ptr-len = cpu_to_be16(len);
+ ptr-j_extent = 0;
+
+ if (dir != DMA_NONE)
+ sg_count = talitos_map_sg(dev, dst, edesc-dst_nents ? : 1,
+ dir, edesc-dst_chained);
+
+ if (sg_count == 1) {
+ to_talitos_ptr(ptr, sg_dma_address(dst));
+ } else {
+ struct talitos_ptr *link_tbl_ptr =
+ edesc-link_tbl[edesc-src_nents + 1];
+
+ to_talitos_ptr(ptr, edesc-dma_link_tbl +
+ (edesc-src_nents + 1) *
+ sizeof(struct talitos_ptr));
+ ptr-j_extent |= DESC_PTR_LNKTBL_JUMP;
+ sg_count = sg_to_link_tbl(dst, sg_count, len, link_tbl_ptr);
+ dma_sync_single_for_device(dev, edesc-dma_link_tbl,
+ edesc-dma_len, DMA_BIDIRECTIONAL);
+ }
+}
+
static int common_nonsnoop(struct talitos_edesc *edesc,
struct ablkcipher_request *areq,
void (*callback) (struct device *dev,
@@ -1387,56 +1453,16 @@ static int common_nonsnoop(struct talitos_edesc *edesc,
/*
* cipher in
*/
- desc-ptr[3].len = cpu_to_be16(cryptlen);
- desc-ptr[3].j_extent = 0;
-
- sg_count = talitos_map_sg(dev, areq-src, edesc-src_nents ? : 1,
- (areq-src == areq-dst) ? DMA_BIDIRECTIONAL
- : DMA_TO_DEVICE,
- edesc-src_chained);
-
- if (sg_count == 1) {
- to_talitos_ptr(desc-ptr[3], sg_dma_address(areq-src));
- } else {
- sg_count = sg_to_link_tbl(areq-src,
[PATCH v3 07/17] crypto: talitos - enhanced talitos_desc struct for SEC1
This patch enhances the talitos_desc struct with fields for SEC1.
SEC1 has only one header field, and has a 'next_desc' field in
addition.
This mixed descriptor will continue to fit SEC2, and for SEC1
we will recopy hdr value into hdr1 value in talitos_submit()
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
drivers/crypto/talitos.h | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 61a1405..f078da1 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -37,9 +37,17 @@
/* descriptor pointer entry */
struct talitos_ptr {
- __be16 len; /* length */
- u8 j_extent;/* jump to sg link table and/or extent */
- u8 eptr;/* extended address */
+ union {
+ struct {/* SEC2 format */
+ __be16 len; /* length */
+ u8 j_extent;/* jump to sg link table and/or extent*/
+ u8 eptr;/* extended address */
+ };
+ struct {/* SEC1 format */
+ __be16 res;
+ __be16 len1;/* length */
+ };
+ };
__be32 ptr; /* address */
};
@@ -53,8 +61,12 @@ static const struct talitos_ptr zero_entry = {
/* descriptor */
struct talitos_desc {
__be32 hdr; /* header high bits */
- __be32 hdr_lo; /* header low bits */
+ union {
+ __be32 hdr_lo; /* header low bits */
+ __be32 hdr1;/* header for SEC1 */
+ };
struct talitos_ptr ptr[7]; /* ptr/len pair array */
+ __be32 next_desc; /* next descriptor (SEC1) */
};
/**
--
2.1.0
--
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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote: Hi Maxime, On 17/04/2015 16:32, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote: Hi Gregory, On Fri, 17 Apr 2015 15:01:01 +0200 Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. I like the idea :-). Not really, how do you know which device is going to be probed? For that matter, it's pretty much random, and you have no control over it. Why not just have a choice option, and select which one you want to enable? Because you can't prevent an user to build a module, then modifying the configuration and building the other module. Well, actually, you don't even know if it's going to be a module. You might very well have both drivers compiled statically in the kernel image, and this is where the trouble begins. So even if there is a choice at build time, and I think that it is something expected for the v2, we still need preventing having the both drivers trying accessing the same hardware in the same time. Of course, but this is already there, and doesn't really address the same issue. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
On 17/04/2015 16:50, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote: Hi Maxime, On 17/04/2015 16:32, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote: Hi Gregory, On Fri, 17 Apr 2015 15:01:01 +0200 Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. I like the idea :-). Not really, how do you know which device is going to be probed? For that matter, it's pretty much random, and you have no control over it. Why not just have a choice option, and select which one you want to enable? Because you can't prevent an user to build a module, then modifying the configuration and building the other module. Well, actually, you don't even know if it's going to be a module. You might very well have both drivers compiled statically in the kernel image, and this is where the trouble begins. No it won't be possible, Boris already speak about this issue (see below): Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). So even if there is a choice at build time, and I think that it is something expected for the v2, we still need preventing having the both drivers trying accessing the same hardware in the same time. Of course, but this is already there, and doesn't really address the same issue. This was the only issue remaining, (see below again): I don't know how to make it a runtime check . And my last emails was bout it. Gregory Maxime -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
On 17/04/2015 17:49, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 05:01:55PM +0200, Gregory CLEMENT wrote: On 17/04/2015 16:50, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote: Hi Maxime, On 17/04/2015 16:32, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote: Hi Gregory, On Fri, 17 Apr 2015 15:01:01 +0200 Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. I like the idea :-). Not really, how do you know which device is going to be probed? For that matter, it's pretty much random, and you have no control over it. Why not just have a choice option, and select which one you want to enable? Because you can't prevent an user to build a module, then modifying the configuration and building the other module. Well, actually, you don't even know if it's going to be a module. You might very well have both drivers compiled statically in the kernel image, and this is where the trouble begins. No it won't be possible, Boris already speak about this issue (see below): Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). Which is a circular dependency and won't work. Indeed. Boris what about using choice/endchoice ? Thanks, Gregory So even if there is a choice at build time, and I think that it is something expected for the v2, we still need preventing having the both drivers trying accessing the same hardware in the same time. Of course, but this is already there, and doesn't really address the same issue. This was the only issue remaining, (see below again): I don't know how to make it a runtime check . And my last emails was bout it. Ok, my bad then :) Maxime -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
On Fri, Apr 17, 2015 at 05:01:55PM +0200, Gregory CLEMENT wrote: On 17/04/2015 16:50, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote: Hi Maxime, On 17/04/2015 16:32, Maxime Ripard wrote: On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote: Hi Gregory, On Fri, 17 Apr 2015 15:01:01 +0200 Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Boris, On 17/04/2015 10:39, Boris Brezillon wrote: On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon boris.brezil...@free-electrons.com wrote: Hi Jason, On Mon, 13 Apr 2015 20:11:46 + Jason Cooper ja...@lakedaemon.net wrote: I'd appreciate if we'd look into it. I understand from on-list and off-list discussion that the rewrite was unavoidable. So I'm willing to concede that. Giving people time to migrate from old to new while still being able to update for other security fixes seems reasonable. Jason, what do you think of the approach above? I say keep it simple. We shouldn't use the DT changes to trigger one vice the other. We need to be able to build both, but only load one at a time. If that's anything other than simple to do, then we make it a Kconfig binary choice and move on. Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). I don't know how to make it a runtime check without adding new compatible strings for the kirkwood, dove and orion platforms, and I'm sure sure this is a good idea. ^ not Do you have any ideas ? You use devm_ioremap_resource() in the new driver, so if the old one is already loaded the memory region will be already hold and the new driver will simply fail during the probe. So for this part it is OK. I like the idea :-). Not really, how do you know which device is going to be probed? For that matter, it's pretty much random, and you have no control over it. Why not just have a choice option, and select which one you want to enable? Because you can't prevent an user to build a module, then modifying the configuration and building the other module. Well, actually, you don't even know if it's going to be a module. You might very well have both drivers compiled statically in the kernel image, and this is where the trouble begins. No it won't be possible, Boris already speak about this issue (see below): Actually I was planning to handle it with a Kconfig dependency rule (NEW_DRIVER depends on !OLD_DRIVER and OLD_DRIVER depends on !NEW_DRIVER). Which is a circular dependency and won't work. So even if there is a choice at build time, and I think that it is something expected for the v2, we still need preventing having the both drivers trying accessing the same hardware in the same time. Of course, but this is already there, and doesn't really address the same issue. This was the only issue remaining, (see below again): I don't know how to make it a runtime check . And my last emails was bout it. Ok, my bad then :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v3 03/17] crypto: talitos - talitos_ptr renamed ptr for more lisibility
Le 17/04/2015 17:14, David Laight a écrit :
From: Christophe Leroy
Linux CodyingStyle recommends to use short variables for local
variables. ptr is just good enough for those 3 lines functions.
It helps keep single lines shorter than 80 characters.
...
-static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t
dma_addr)
+static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr)
{
- talitos_ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
- talitos_ptr-eptr = upper_32_bits(dma_addr);
+ ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
+ ptr-eptr = upper_32_bits(dma_addr);
}
...
Maybe, but 'ptr' isn't a good choice.
Any suggestion ?
Christophe
--
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
RE: [PATCH v3 03/17] crypto: talitos - talitos_ptr renamed ptr for more lisibility
From: Christophe Leroy
Linux CodyingStyle recommends to use short variables for local
variables. ptr is just good enough for those 3 lines functions.
It helps keep single lines shorter than 80 characters.
...
-static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t
dma_addr)
+static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr)
{
- talitos_ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
- talitos_ptr-eptr = upper_32_bits(dma_addr);
+ ptr-ptr = cpu_to_be32(lower_32_bits(dma_addr));
+ ptr-eptr = upper_32_bits(dma_addr);
}
...
Maybe, but 'ptr' isn't a good choice.
David
N�r��yb�X��ǧv�^�){.n�+{�r����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [PATCH v3 00/17] crypto: talitos - Add support for SEC1
On Fri, Apr 17, Christophe Leroy wrote: v3 is a complete rework of the patchset. Since a kernel can be built with support for both MPC82xx and MPC83xx at the same time, talitos driver shall support both SEC1 and SEC2+ at the same time. The used git send-email command lacked the --thread option. From this perspective: NACK to the whole series... Olaf -- 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] crypto: Fix aead_{sendmsg,recvmsg}() signatures.
The kiocb argument is no longer present.
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 527d27b..95ad689 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -163,8 +163,7 @@ static void aead_data_wakeup(struct sock *sk)
rcu_read_unlock();
}
-static int aead_sendmsg(struct kiocb *unused, struct socket *sock,
- struct msghdr *msg, size_t size)
+static int aead_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
{
struct sock *sk = sock-sk;
struct alg_sock *ask = alg_sk(sk);
@@ -348,8 +347,8 @@ unlock:
return err ?: size;
}
-static int aead_recvmsg(struct kiocb *unused, struct socket *sock,
- struct msghdr *msg, size_t ignored, int flags)
+static int aead_recvmsg(struct socket *sock, struct msghdr *msg,
+ size_t ignored, int flags)
{
struct sock *sk = sock-sk;
struct alg_sock *ask = alg_sk(sk);
--
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
Re: [PATCH] crypto: Fix aead_{sendmsg,recvmsg}() signatures.
From: Herbert Xu herb...@gondor.apana.org.au Date: Sat, 18 Apr 2015 09:33:17 +0800 On Fri, Apr 17, 2015 at 03:19:53PM -0400, David Miller wrote: The kiocb argument is no longer present. Signed-off-by: David S. Miller da...@davemloft.net I think Linus has already fixed this with commit eccd02f32a2c25139da2d5e72ebab1fee7b5baab Author: Linus Torvalds torva...@linux-foundation.org Date: Wed Apr 15 14:09:46 2015 -0700 crypto: fix mis-merge with the networking merge Awesome, thanks Herbert. -- 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
Re: DRBG seeding
Am Samstag, 18. April 2015, 09:36:18 schrieb Herbert Xu: Hi Herbert, On Sat, Apr 18, 2015 at 03:32:03AM +0200, Stephan Mueller wrote: In any case, I am almost ready with the patch for an async seeding. Though, I want to give it a thorough testing. I don't see the point of async seeding, unless you're also making all generate calls block until the seeding is complete. My plan is seeding first with /dev/urandom followed by the async /dev/random call. I.e. during the instantiation of the DRBG, the get_random_bytes is pulled for the initial seed. At the same time the async trigger to get data from /dev/random is made. Once that async call returns, the DRBG is re-seeded with that data. Any immediate call to any in-kernel /dev/random and block really can cause the DRBG to stall. If the DRBG is the stdrng, we invite serious regressions if we block during initialization, especially in headless systems. Furthermore, the DRBG is implemented to pull the nonce also from the seed source. As outlined in section 8.6.3 of SP800-90A, the nonce is used as a cushion if the entropy string does not have sufficient entropy. However, the only serious solution I can offer to not block is to use my Jitter RNG which delivers entropy in (almost all) use cases. See [1]. The code is relatively small and does not have any dependencies. In this case, we could perform the initialization of the DRBG as follows: 1. pull buffer of size entropy + nonce from get_random_bytes 2. pull another buffer of size entropy + nonce from my Jitter RNG 3. XOR both 4. seed the DRBG with it 5. trigger the async invocation of the in-kernel /dev/random 6. return the DRBG instance to the caller without waiting for the completion of step 5 This way, we will get entropy during the first initialization without blocking. After speaking with mathematicians at NIST, that Jitter RNG approach would be accepted. Note, I personally think that the Jitter RNG has sufficient entropy in almost all circumstances (see the massive testing I conducted on all more widely used CPUs). [1] http://www.chronox.de/jent.html -- Ciao Stephan -- 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
Re: DRBG seeding
On Sat, Apr 18, 2015 at 04:04:14AM +0200, Stephan Mueller wrote: However, the only serious solution I can offer to not block is to use my Jitter RNG which delivers entropy in (almost all) use cases. See [1]. The code is relatively small and does not have any dependencies. In this case, we could perform the initialization of the DRBG as follows: 1. pull buffer of size entropy + nonce from get_random_bytes 2. pull another buffer of size entropy + nonce from my Jitter RNG 3. XOR both Don't xor them. Just provide them both as input to the seed function. 4. seed the DRBG with it 5. trigger the async invocation of the in-kernel /dev/random 6. return the DRBG instance to the caller without waiting for the completion of step 5 This way, we will get entropy during the first initialization without blocking. After speaking with mathematicians at NIST, that Jitter RNG approach would be accepted. Note, I personally think that the Jitter RNG has sufficient entropy in almost all circumstances (see the massive testing I conducted on all more widely used CPUs). [1] http://www.chronox.de/jent.html OK this sounds like it should satisfy everybody. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
Re: DRBG seeding
Am Samstag, 18. April 2015, 09:27:44 schrieb Herbert Xu: Hi Herbert, On Fri, Apr 17, 2015 at 03:22:56PM +0200, Stephan Mueller wrote: The only reason someone would use this is to comply with the standard and this is what the standard requires so I don't see how we can do anything else. I do not see a definite quality requirement of the seed source in SP800-90A. Section 8.6.5 Source of Entropy Input explicitly requires this. TBH whether /dev/random even satisfies 8.6.5 is also debatable. But it agrees with the specification at least in spirit. Ok, if I re-read that one and consider our discussion, I would agree. But it was handled differently up to now. In any case, I am almost ready with the patch for an async seeding. Though, I want to give it a thorough testing. -- Ciao Stephan -- 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
Re: [PATCH] crypto: Fix aead_{sendmsg,recvmsg}() signatures.
On Fri, Apr 17, 2015 at 03:19:53PM -0400, David Miller wrote: The kiocb argument is no longer present. Signed-off-by: David S. Miller da...@davemloft.net I think Linus has already fixed this with commit eccd02f32a2c25139da2d5e72ebab1fee7b5baab Author: Linus Torvalds torva...@linux-foundation.org Date: Wed Apr 15 14:09:46 2015 -0700 crypto: fix mis-merge with the networking merge Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
Re: DRBG seeding
On Sat, Apr 18, 2015 at 03:32:03AM +0200, Stephan Mueller wrote: In any case, I am almost ready with the patch for an async seeding. Though, I want to give it a thorough testing. I don't see the point of async seeding, unless you're also making all generate calls block until the seeding is complete. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
Re: DRBG seeding
On Fri, Apr 17, 2015 at 03:22:56PM +0200, Stephan Mueller wrote: The only reason someone would use this is to comply with the standard and this is what the standard requires so I don't see how we can do anything else. I do not see a definite quality requirement of the seed source in SP800-90A. Section 8.6.5 Source of Entropy Input explicitly requires this. TBH whether /dev/random even satisfies 8.6.5 is also debatable. But it agrees with the specification at least in spirit. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
