Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API
Am Montag, 19. Oktober 2015, 09:32:30 schrieb Herbert Xu: Hi Herbert, > On Sun, Oct 18, 2015 at 12:44:00PM +0200, Stephan Mueller wrote: > > Hi, > > > > This patch set adds the AF_ALG user space API to externalize the > > asymmetric cipher API recently added to the kernel crypto API. > > > > The patch set is tested with the user space library of libkcapi [1]. > > Use [1] test/test.sh for a full test run. The test covers the > > > following scenarios: > Thanks Stephan. But I would prefer to defer this til after we have > completed the conversion of current in-kernel users. This is because > changing the kernel interface is easy while changing the user-space > interface is not. Sure, let us wait. However, I would suggest that you pull patch 1/5 as this is a bug fix that may affect even other users. -- 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 v2 0/5] crypto: add algif_akcipher user space API
On Mon, Oct 19, 2015 at 09:14:09AM +0200, Stephan Mueller wrote: > > However, I would suggest that you pull patch 1/5 as this is a bug fix that > may > affect even other users. Sure I'll look into it. Thanks, -- Email: Herbert Xu 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
crypto: api - Only abort operations on fatal signal
Currently a number of Crypto API operations may fail when a signal
occurs. This causes nasty problems as the caller of those operations
are often not in a good position to restart the operation.
In fact there is currently no need for those operations to be
interrupted by user signals at all. All we need is for them to
be killable.
This patch replaces the relevant calls of signal_pending with
fatal_signal_pending, and wait_for_completion_interruptible with
wait_for_completion_killable, respectively.
Signed-off-by: Herbert Xu
diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index b788f16..b4ffc5b 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -706,7 +706,7 @@ struct crypto_ablkcipher *crypto_alloc_ablkcipher(const
char *alg_name,
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
diff --git a/crypto/algapi.c b/crypto/algapi.c
index d130b41..59bf491 100644
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -345,7 +345,7 @@ static void crypto_wait_for_test(struct crypto_larval
*larval)
crypto_alg_tested(larval->alg.cra_driver_name, 0);
}
- err = wait_for_completion_interruptible(&larval->completion);
+ err = wait_for_completion_killable(&larval->completion);
WARN_ON(err);
out:
diff --git a/crypto/api.c b/crypto/api.c
index afe4610..bbc147c 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -172,7 +172,7 @@ static struct crypto_alg *crypto_larval_wait(struct
crypto_alg *alg)
struct crypto_larval *larval = (void *)alg;
long timeout;
- timeout = wait_for_completion_interruptible_timeout(
+ timeout = wait_for_completion_killable_timeout(
&larval->completion, 60 * HZ);
alg = larval->adult;
@@ -445,7 +445,7 @@ struct crypto_tfm *crypto_alloc_base(const char *alg_name,
u32 type, u32 mask)
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
@@ -562,7 +562,7 @@ void *crypto_alloc_tfm(const char *alg_name,
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
diff --git a/crypto/crypto_user.c b/crypto/crypto_user.c
index d94d99f..237f379 100644
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -375,7 +375,7 @@ static struct crypto_alg *crypto_user_skcipher_alg(const
char *name, u32 type,
err = PTR_ERR(alg);
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
--
Email: Herbert Xu
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
[PATCH] akcipher: Don't #include crypto/public_key.h as the contents aren't used
Don't #include crypto/public_key.h in akcipher as the contents of the header aren't used and changes in a future patch cause it to fail to compile if CONFIG_KEYS=n. Signed-off-by: David Howells --- crypto/akcipher.c |1 - 1 file changed, 1 deletion(-) diff --git a/crypto/akcipher.c b/crypto/akcipher.c index 528ae6aa9bff..120ec042ec9e 100644 --- a/crypto/akcipher.c +++ b/crypto/akcipher.c @@ -21,7 +21,6 @@ #include #include #include -#include #include "internal.h" #ifdef CONFIG_NET -- 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 03/18] crypto: marvell: add flag to determine algorithm endianness
Hey Russell,
On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> Rather than determining whether we're using a MD5 hash by looking at
> the digest size, switch to a cleaner solution using a per-request flag
> initialised by the method type.
>
> Signed-off-by: Russell King
> ---
> drivers/crypto/marvell/cesa.h | 1 +
> drivers/crypto/marvell/hash.c | 17 +
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
...
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index f59faabcd34f..aa12274608ab 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -351,7 +351,7 @@ static int mv_cesa_ahash_process(struct
> crypto_async_request *req, u32 status)
>* Hardware's MD5 digest is in little endian format, but
>* SHA in big endian format
>*/
> - if (digsize == MD5_DIGEST_SIZE) {
> + if (creq->algo_le) {
> __le32 *result = (void *)ahashreq->result;
>
> for (i = 0; i < digsize / 4; i++)
> @@ -407,7 +407,7 @@ static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops
> = {
> };
>
> static int mv_cesa_ahash_init(struct ahash_request *req,
> - struct mv_cesa_op_ctx *tmpl)
> + struct mv_cesa_op_ctx *tmpl, bool algo_le)
nit: Would it make more sense the do bool algo_endian, and then ...
> @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
>
> mv_cesa_set_op_cfg(&tmpl, CESA_SA_DESC_CFG_MACM_MD5);
>
> - mv_cesa_ahash_init(req, &tmpl);
> + mv_cesa_ahash_init(req, &tmpl, true);
mv_cesa_ahash_init(req, &tmpl, ALGO_ENDIAN_LITTLE);
'true' doesn't seem as obvious. But again, nit-picky.
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
Re: [PATCH 03/18] crypto: marvell: add flag to determine algorithm endianness
On Mon, Oct 19, 2015 at 03:04:51PM +, Jason Cooper wrote:
> Hey Russell,
>
> On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> > static int mv_cesa_ahash_init(struct ahash_request *req,
> > - struct mv_cesa_op_ctx *tmpl)
> > + struct mv_cesa_op_ctx *tmpl, bool algo_le)
>
> nit: Would it make more sense the do bool algo_endian, and then ...
I don't like "bool"s that don't self-document what they mean.
What does "if (algo_endian)" mean? It's pretty clear what
"if (algo_le)" means in the context of endianness, though I'll
give you that "if (algo_little_endian)" would be a lot better.
>
> > @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
> >
> > mv_cesa_set_op_cfg(&tmpl, CESA_SA_DESC_CFG_MACM_MD5);
> >
> > - mv_cesa_ahash_init(req, &tmpl);
> > + mv_cesa_ahash_init(req, &tmpl, true);
>
> mv_cesa_ahash_init(req, &tmpl, ALGO_ENDIAN_LITTLE);
>
> 'true' doesn't seem as obvious. But again, nit-picky.
I did think about:
enum {
ALGO_LITTLE_ENDIAN,
ALGO_BIG_ENDIAN,
};
and passing an int algo_endian around, but that seemed to be like too
much bloat... though if you want to insist, I could make that change.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/3] ARM: dts: Enable Exynos RNG module
Hello Krzysztof,
I can confirm that this also works on a Odroid-X2, so I guess it's safe
to enable the PRNG for all Exynos4412-based Odroid devices.
Any chance that you might also take a look at the other hwcrypto stuff
on the SoC ('samsung,exynos4210-secss' compatible)?
With best wishes,
Tobias
Krzysztof Kozlowski wrote:
> Hi,
>
>
> The patchset adds necessary clock from Security SubSystem (SSS)
> and enables the PRNG module of Exynos for Trats2 board.
>
> The first patch (clock) is required for other ones so please
> take everything in one step.
>
> The actual Device Tree support (and compatible) was sent in separate
> patch:
> - https://patchwork.kernel.org/patch/7432891/
> - http://marc.info/?l=linux-crypto-vger&m=144522952725052&w=2
>
> The device can be tested (after applying both patchsets) with:
> $ echo exynos > /sys/class/misc/hw_random/rng_current
> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
>
>
> Best regards,
> Krzysztof
>
> Krzysztof Kozlowski (3):
> clk: samsung: exynos4: Add SSS gate clock
> ARM: dts: Add PRNG module for exynos4
> ARM: dts: Enable PRNG module on exynos4412-trats2
>
> arch/arm/boot/dts/exynos4.dtsi | 8
> arch/arm/boot/dts/exynos4412-trats2.dts | 4
> drivers/clk/samsung/clk-exynos4.c | 1 +
> include/dt-bindings/clock/exynos4.h | 1 +
> 4 files changed, 14 insertions(+)
>
--
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 03/18] crypto: marvell: add flag to determine algorithm endianness
On Mon, Oct 19, 2015 at 04:25:07PM +0100, Russell King - ARM Linux wrote:
>
> > > @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
> > >
> > > mv_cesa_set_op_cfg(&tmpl, CESA_SA_DESC_CFG_MACM_MD5);
> > >
> > > - mv_cesa_ahash_init(req, &tmpl);
> > > + mv_cesa_ahash_init(req, &tmpl, true);
> >
> > mv_cesa_ahash_init(req, &tmpl, ALGO_ENDIAN_LITTLE);
> >
> > 'true' doesn't seem as obvious. But again, nit-picky.
>
> I did think about:
>
> enum {
> ALGO_LITTLE_ENDIAN,
> ALGO_BIG_ENDIAN,
> };
>
> and passing an int algo_endian around, but that seemed to be like too
> much bloat... though if you want to insist, I could make that change.
I think the patch is fine as it is.
Thanks,
--
Email: Herbert Xu
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: [PATCH 03/18] crypto: marvell: add flag to determine algorithm endianness
On Mon, Oct 19, 2015 at 04:25:07PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 03:04:51PM +, Jason Cooper wrote:
> > Hey Russell,
> >
> > On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote:
> > > static int mv_cesa_ahash_init(struct ahash_request *req,
> > > - struct mv_cesa_op_ctx *tmpl)
> > > + struct mv_cesa_op_ctx *tmpl, bool algo_le)
> >
> > nit: Would it make more sense the do bool algo_endian, and then ...
>
> I don't like "bool"s that don't self-document what they mean.
> What does "if (algo_endian)" mean? It's pretty clear what
That's where I would go with an enum. "if (algo_endian ==
ALGO_ENDIAN_LITTLE) ..."
> "if (algo_le)" means in the context of endianness, though I'll
> give you that "if (algo_little_endian)" would be a lot better.
Right, it's really a question of where do we want readability? I was
focusing on the call site, since the context isn't there for newcomers to
easily grok 'true'.
> > > @@ -861,7 +862,7 @@ static int mv_cesa_md5_init(struct ahash_request *req)
> > >
> > > mv_cesa_set_op_cfg(&tmpl, CESA_SA_DESC_CFG_MACM_MD5);
> > >
> > > - mv_cesa_ahash_init(req, &tmpl);
> > > + mv_cesa_ahash_init(req, &tmpl, true);
> >
> > mv_cesa_ahash_init(req, &tmpl, ALGO_ENDIAN_LITTLE);
> >
> > 'true' doesn't seem as obvious. But again, nit-picky.
>
> I did think about:
>
> enum {
> ALGO_LITTLE_ENDIAN,
> ALGO_BIG_ENDIAN,
> };
>
> and passing an int algo_endian around, but that seemed to be like too
> much bloat... though if you want to insist, I could make that change.
Like I said, it's a nit. Either a self-documenting bool, or an enum
will work.
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
Re: [PATCH 1/3] clk: samsung: exynos4: Add SSS gate clock
On 10/19, Krzysztof Kozlowski wrote: > Add a gate clock for controlling all clocks of Security Sub System > (SSS). > > Signed-off-by: Krzysztof Kozlowski > --- The To: list is huge, so I have no idea if you want me to apply this patch or not, and given that it's part of a series that has dts changes I guess that means it should go through arm-soc: Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 0/2] xfrm/crypto: unaligned access fixes
A two-part patchset that fixes some "unaligned access" warnings that showed up my sparc test machines with ipsec set up. Sowmini Varadhan (2): crypto/x509: Fix unaligned access in x509_get_sig_params() Fix unaligned access in xfrm_notify_sa() for DELSA crypto/asymmetric_keys/x509_public_key.c |5 +++-- net/xfrm/xfrm_user.c |2 +- 2 files changed, 4 insertions(+), 3 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 net-next 2/2] xfrm: Fix unaligned access in xfrm_notify_sa() for DELSA
On sparc, deleting established SAs (e.g., by restarting ipsec at the peer) results in unaligned access messages via xfrm_del_sa -> km_state_notify -> xfrm_send_state_notify(). Use an aligned pointer to xfrm_usersa_info for this case. Signed-off-by: Sowmini Varadhan --- net/xfrm/xfrm_user.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c index a8de9e3..158ef4a 100644 --- a/net/xfrm/xfrm_user.c +++ b/net/xfrm/xfrm_user.c @@ -2659,7 +2659,7 @@ static int xfrm_notify_sa(struct xfrm_state *x, const struct km_event *c) if (attr == NULL) goto out_free_skb; - p = nla_data(attr); + p = PTR_ALIGN(nla_data(attr), __alignof__(*p)); } err = copy_to_user_state_extra(x, p, skb); if (err) -- 1.7.1 -- 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/2] crypto/x509: Fix unaligned access in x509_get_sig_params()
x509_get_sig_params() has the same code pattern as the one in
pkcs7_verify() that is fixed by commit 62f57d05e287 ("crypto: pkcs7 - Fix
unaligned access in pkcs7_verify()") so apply a similar fix here: make
sure that desc is pointing at an algined value past the digest_size,
and take alignment values into consideration when doing kzalloc()
Signed-off-by: Sowmini Varadhan
---
crypto/asymmetric_keys/x509_public_key.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_public_key.c
index 1970966..68c3c40 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -194,14 +194,15 @@ int x509_get_sig_params(struct x509_certificate *cert)
* digest storage space.
*/
ret = -ENOMEM;
- digest = kzalloc(digest_size + desc_size, GFP_KERNEL);
+ digest = kzalloc(ALIGN(digest_size, __alignof__(*desc)) + desc_size,
+GFP_KERNEL);
if (!digest)
goto error;
cert->sig.digest = digest;
cert->sig.digest_size = digest_size;
- desc = digest + digest_size;
+ desc = PTR_ALIGN(digest + digest_size, __alignof__(*desc));
desc->tfm = tfm;
desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
--
1.7.1
--
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 17/18] crypto: marvell: fix first-fragment handling in mv_cesa_ahash_dma_last_req()
Hi Russell, Russell King writes: > When adding the software padding, this must be done using the first/mid > fragment mode, and any subsequent operation needs to be a mid-fragment. > Fix this. > > Signed-off-by: Russell King > --- > drivers/crypto/marvell/hash.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c > index da541e59cc1d..34271e9eb3a5 100644 > --- a/drivers/crypto/marvell/hash.c > +++ b/drivers/crypto/marvell/hash.c > @@ -575,20 +575,12 @@ mv_cesa_ahash_dma_last_req(struct mv_cesa_tdma_chain > *chain, > if (IS_ERR(op)) > return op; > > - mv_cesa_update_op_cfg(op, CESA_SA_DESC_CFG_MID_FRAG, > - CESA_SA_DESC_CFG_FRAG_MSK); > - > if (len == trailerlen) > return op; > > padoff += len; > } > > - if (!mv_cesa_mac_op_is_first_frag(&creq->op_tmpl)) > - mv_cesa_update_op_cfg(&creq->op_tmpl, > - CESA_SA_DESC_CFG_MID_FRAG, > - CESA_SA_DESC_CFG_FRAG_MSK); > - > ret = mv_cesa_dma_add_data_transfer(chain, > CESA_SA_DATA_SRAM_OFFSET, > ahashdreq->padding_dma + I'll consider it's just late here and I need some sleep but I fail to align the commit message w/ the content of the patch, i.e. it's unclear to me. Cheers, a+ -- 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 00/18] crypto: further fixes for Marvell CESA hash
Hi Russell, Boris Brezillon writes: > On Sun, 18 Oct 2015 17:16:49 +0100 > Russell King - ARM Linux wrote: > >> Following on from the previous series, this series addresses further >> problems with the Marvell CESA hash driver found while testing it my >> openssl/ssh scenarios. >> >> The first patch improves one from the previous series: we can get the >> transform more directly using req->base.tfm rather than going round >> the houses. >> >> The next few patches rework the algorithm endianness conversions. >> There are two things which depend on the algorithm endianness - the >> format of the result, and the format of the bit length in the last >> block. We introduce a flag to convey this information, and keep >> the creq->state format in CPU endian mode for consistency. >> >> Some of the inconsistent hash results are down to the template >> operation not being properly initialised - so we zero initialise all >> template operations. >> >> The following patches (from "factor out first fragment decisions to >> helper") rework the digest handling to ensure that we always provide >> the hardware with a complete block of data to hash, otherwise it can >> be left mid-calculation, which then causes state to leak to >> subsequent operations. This requires a re-structure of the way we >> put together the DMA entries, so it's done in relatively small steps. >> >> This results in the CESA driver passing all tests I can throw at it >> via the AF_ALG openssl plugin with the exception of asking for the >> hash of /dev/null. This returns an all zero result, rather than the >> correct hash value. This bug is pending further diagnosis, but it >> is believed not to be a driver specific bug as iMX6 CAAM also behaves >> the same. >> >> Unfortunately, this is a large series, but the driver unfortunately >> needs this level of bug fixing to work properly. > > Thanks for spending some time fixing those bugs and > simplifying/factorizing/documenting the hash logic. +1 > To the whole series: > > Acked-by: Boris Brezillon > > Note that my ack might seem quite quick compared to the amount of > changes, but Russell actually sent me a preliminary version last > Wednesday. > > Arnaud, if you have some time, could you also have a look at those > patches? Acked-by: Arnaud Ebalard Cheers, a+ -- 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 4/6] crypto: marvell: use memcpy_fromio()/memcpy_toio()
Hi Russell,
Russell King writes:
> Use the IO memcpy() functions when copying from/to MMIO memory.
> These locations were found via sparse.
On recent MVEBU hardware, *_std_* function are not expected to be used
because we will instead use the TDMA-based versions. So the only
possible penalty we could get (if any) from this change on recent
devices is for the copy of the IV in mv_cesa_ablkcipher_process(). Out
of curiosity, I took a quick look at what is generated and it seems this
results in a call to mmiocpy():
0340 :
340: e1a0c00dmov ip, sp
344: e92dd830push{r4, r5, fp, ip, lr, pc}
348: e24cb004sub fp, ip, #4
34c: e24dd008sub sp, sp, #8
3a4: e5943010ldr r3, [r4, #16]
3a8: e5951008ldr r1, [r5, #8]
3ac: e594001cldr r0, [r4, #28]
3b0: e2811040add r1, r1, #64 ; 0x40
3b4: e593201cldr r2, [r3, #28]
3b8: ebfebl 0
which if I am not mistaken is provided by arch/arm/lib/memcpy.S via:
ENTRY(mmiocpy)
ENTRY(memcpy)
#include "copy_template.S"
ENDPROC(memcpy)
ENDPROC(mmiocpy)
Am I right in concluding this will end up being the code of a usual
memcpy(), i.e. the change is a noop in the final code compared to
previous version?
Cheers,
a+
>
> Signed-off-by: Russell King
> ---
> drivers/crypto/marvell/cipher.c | 11 ++-
> drivers/crypto/marvell/hash.c | 16
> 2 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/crypto/marvell/cipher.c b/drivers/crypto/marvell/cipher.c
> index 4db2d632204f..6edae64bb387 100644
> --- a/drivers/crypto/marvell/cipher.c
> +++ b/drivers/crypto/marvell/cipher.c
> @@ -98,10 +98,10 @@ static void mv_cesa_ablkcipher_std_step(struct
> ablkcipher_request *req)
>
> /* FIXME: only update enc_len field */
> if (!sreq->skip_ctx) {
> - memcpy(engine->sram, &sreq->op, sizeof(sreq->op));
> + memcpy_toio(engine->sram, &sreq->op, sizeof(sreq->op));
> sreq->skip_ctx = true;
> } else {
> - memcpy(engine->sram, &sreq->op, sizeof(sreq->op.desc));
> + memcpy_toio(engine->sram, &sreq->op, sizeof(sreq->op.desc));
> }
>
> mv_cesa_set_int_mask(engine, CESA_SA_INT_ACCEL0_DONE);
> @@ -145,8 +145,9 @@ static int mv_cesa_ablkcipher_process(struct
> crypto_async_request *req,
> if (ret)
> return ret;
>
> - memcpy(ablkreq->info, engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
> -crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq)));
> + memcpy_fromio(ablkreq->info,
> + engine->sram + CESA_SA_CRYPT_IV_SRAM_OFFSET,
> +
> crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(ablkreq)));
>
> return 0;
> }
> @@ -181,7 +182,7 @@ mv_cesa_ablkcipher_std_prepare(struct ablkcipher_request
> *req)
> sreq->size = 0;
> sreq->offset = 0;
> mv_cesa_adjust_op(engine, &sreq->op);
> - memcpy(engine->sram, &sreq->op, sizeof(sreq->op));
> + memcpy_toio(engine->sram, &sreq->op, sizeof(sreq->op));
> }
>
> static inline void mv_cesa_ablkcipher_prepare(struct crypto_async_request
> *req,
> diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
> index 84ddc4cbfa9d..8330815d72fc 100644
> --- a/drivers/crypto/marvell/hash.c
> +++ b/drivers/crypto/marvell/hash.c
> @@ -209,8 +209,8 @@ static void mv_cesa_ahash_std_step(struct ahash_request
> *req)
> size_t len;
>
> if (creq->cache_ptr)
> - memcpy(engine->sram + CESA_SA_DATA_SRAM_OFFSET, creq->cache,
> -creq->cache_ptr);
> + memcpy_toio(engine->sram + CESA_SA_DATA_SRAM_OFFSET,
> + creq->cache, creq->cache_ptr);
>
> len = min_t(size_t, req->nbytes + creq->cache_ptr - sreq->offset,
> CESA_SA_SRAM_PAYLOAD_SIZE);
> @@ -251,10 +251,10 @@ static void mv_cesa_ahash_std_step(struct ahash_request
> *req)
> if (len + trailerlen > CESA_SA_SRAM_PAYLOAD_SIZE) {
> len &= CESA_HASH_BLOCK_SIZE_MSK;
> new_cache_ptr = 64 - trailerlen;
> - memcpy(creq->cache,
> -engine->sram +
> -CESA_SA_DATA_SRAM_OFFSET + len,
> -new_cache_ptr);
> + memcpy_fromio(creq->cache,
> + engine->sram +
> + CESA_SA_DATA_SRAM_OFFSET + len,
> + new_cache_ptr);
> } else {
> len += mv_cesa_ahash_pad_req(creq,
> engine->sram + len
Re: [PATCH v2 1/5] MPI: fix off by one in mpi_read_raw_from_sgl
On 10/18/2015 03:45 AM, Stephan Mueller wrote:
> The patch fixes the analysis of the input data which contains an off
> by one.
>
> The issue is visible when the SGL contains one byte per SG entry.
> The code for checking for zero bytes does not operate on the data byte.
>
> Signed-off-by: Stephan Mueller
> ---
> lib/mpi/mpicoder.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/mpi/mpicoder.c b/lib/mpi/mpicoder.c
> index c20ef27..c7e0a70 100644
> --- a/lib/mpi/mpicoder.c
> +++ b/lib/mpi/mpicoder.c
> @@ -446,8 +446,11 @@ MPI mpi_read_raw_from_sgl(struct scatterlist *sgl,
> unsigned int len)
> const u8 *buff = sg_virt(sg);
> int len = sg->length;
>
> - while (len-- && !*buff++)
> + while (len && !*buff) {
> lzeros++;
> + len--;
> + buff++;
> + }
>
> if (len && *buff)
> break;
ACK. Thanks for testing this 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/6] Sparse related fixes
Hi, Boris Brezillon writes: > On Sun, 18 Oct 2015 18:30:39 +0100 > Russell King - ARM Linux wrote: > >> Continuing on from the previous set of 18 patches, I also fixed a >> number of sparse problems and other cleanups. I don't deem these >> suitable for -rc merging, especially now that we're basically at >> -rc6. >> >> The first patch switches the driver over to appropriately using >> the relaxed IO accessors - this avoids calling out to the heavy >> barrier on every read and write operation, but only calling out on >> those which really matter. >> >> We switch to using dma_addr_t for DMA addresses which are not accessed >> by hardware, and using gfp_t for the get_free_page flags. String-based >> MMIO accesses are used instead of plain memcpy()/memset() which prevents >> us potentially stumbling over GCC optimisations that it thinks it may >> make with these functions. >> >> We convert as much of the hardware state to __le32 endian markings, >> and use cpu_to_le32() as appropriate. A number of places are left >> unfixed, as we temporarily store CPU native endian values at these >> locations; these warnings should not be fixed (basically, only >> appropriate sparse warnings should be fixed without penalising code.) > > To the whole series: > > Acked-by: Boris Brezillon Same here: Acked-by: Arnaud Ebalard -- 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/3] ARM: dts: Enable Exynos RNG module
On 20.10.2015 01:11, Tobias Jakobi wrote:
> Hello Krzysztof,
>
> I can confirm that this also works on a Odroid-X2, so I guess it's safe
> to enable the PRNG for all Exynos4412-based Odroid devices.
Sure, I can send a patch for that. I can test it later also on Odroid-U3.
>
> Any chance that you might also take a look at the other hwcrypto stuff
> on the SoC ('samsung,exynos4210-secss' compatible)?
What do you mean? The s5p-sss driver already supports Device Tree.
Best regards,
Krzysztof
>
> With best wishes,
> Tobias
>
>
> Krzysztof Kozlowski wrote:
>> Hi,
>>
>>
>> The patchset adds necessary clock from Security SubSystem (SSS)
>> and enables the PRNG module of Exynos for Trats2 board.
>>
>> The first patch (clock) is required for other ones so please
>> take everything in one step.
>>
>> The actual Device Tree support (and compatible) was sent in separate
>> patch:
>> - https://patchwork.kernel.org/patch/7432891/
>> - http://marc.info/?l=linux-crypto-vger&m=144522952725052&w=2
>>
>> The device can be tested (after applying both patchsets) with:
>> $ echo exynos > /sys/class/misc/hw_random/rng_current
>> $ dd if=/dev/hwrng of=/dev/null bs=1 count=16
>>
>>
>> Best regards,
>> Krzysztof
>>
>> Krzysztof Kozlowski (3):
>> clk: samsung: exynos4: Add SSS gate clock
>> ARM: dts: Add PRNG module for exynos4
>> ARM: dts: Enable PRNG module on exynos4412-trats2
>>
>> arch/arm/boot/dts/exynos4.dtsi | 8
>> arch/arm/boot/dts/exynos4412-trats2.dts | 4
>> drivers/clk/samsung/clk-exynos4.c | 1 +
>> include/dt-bindings/clock/exynos4.h | 1 +
>> 4 files changed, 14 insertions(+)
>>
>
>
--
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 1/3] clk: samsung: exynos4: Add SSS gate clock
On 20.10.2015 04:59, Stephen Boyd wrote: > On 10/19, Krzysztof Kozlowski wrote: >> Add a gate clock for controlling all clocks of Security Sub System >> (SSS). >> >> Signed-off-by: Krzysztof Kozlowski >> --- > > The To: list is huge, so I have no idea if you want me to apply > this patch or not, and given that it's part of a series that has > dts changes I guess that means it should go through arm-soc: > > Acked-by: Stephen Boyd If you are OK with that I would like to push it through arm-soc. Thanks for the ack! Best regards, Krzysztof -- 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
