From: Corentin LABBE <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v4 3/3] crypto: Add Allwinner Security System crypto accelerator
Date: Sat, 26 Jul 2014 16:01:26 +0200 [thread overview]
Message-ID: <53D3B4B6.3000100@gmail.com> (raw)
In-Reply-To: <20140724133823.GA9638-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Le 24/07/2014 15:38, Herbert Xu a écrit :
> On Thu, Jul 24, 2014 at 01:04:55PM +0200, Corentin LABBE wrote:
>> Le 24/07/2014 08:00, Herbert Xu a écrit :
>>> On Sat, Jul 12, 2014 at 02:59:13PM +0200, LABBE Corentin wrote:
>>>>
>>>> +/* sunxi_hash_init: initialize request context
>>>> + * Activate the SS, and configure it for MD5 or SHA1
>>>> + */
>>>> +int sunxi_hash_init(struct ahash_request *areq)
>>>> +{
>>>> + const char *hash_type;
>>>> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
>>>> + struct sunxi_req_ctx *op = crypto_ahash_ctx(tfm);
>>>> +
>>>> + mutex_lock(&ss->lock);
>>>> +
>>>> + hash_type = crypto_tfm_alg_name(areq->base.tfm);
>>>> +
>>>> + op->byte_count = 0;
>>>> + op->nbwait = 0;
>>>> + op->waitbuf = 0;
>>>> +
>>>> + /* Enable and configure SS for MD5 or SHA1 */
>>>> + if (strcmp(hash_type, "sha1") == 0)
>>>> + op->mode = SS_OP_SHA1;
>>>> + else
>>>> + op->mode = SS_OP_MD5;
>>>> +
>>>> + writel(op->mode | SS_ENABLED, ss->base + SS_CTL);
>>>> + return 0;
>>>
>>> The hash driver is completely broken. You are modifying tfm
>>> ctx data which is shared by all users of a single tfm. So
>>> if two users conduct hashes in parallel they will step all
>>> over each other.
>>
>> So where can I store data for each request ?
>
> Well, first of all you need to stop storing state in the hardware.
> After each operation the hardware may be used by some other user
> for a completely different hash request. So leaving the hash state
> in the hardware is a no-no.
>
> If your hardware supports exporting the hash state then you just
> have to export it after each operation and reimporting before the
> next one.
Even if it is undocumented, the hardware seems to support it.
Since crypto_ahash_ctx is for a tfm, does ahash_request_ctx is the good place to store data ?
(after a call to crypto_ahash_set_reqsize in cra_init)
I have also seen export/import function, does I need to use it ?
>
> If your hardware is incapable of exporting partial hash state then
> you will have to use a software fallback for init/update. If your
> hardware is incapable of importing partial hash state then you will
> also have to do finup/final using a software fallback.
>
> Cheers,
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: clabbe.montjoie@gmail.com (Corentin LABBE)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/3] crypto: Add Allwinner Security System crypto accelerator
Date: Sat, 26 Jul 2014 16:01:26 +0200 [thread overview]
Message-ID: <53D3B4B6.3000100@gmail.com> (raw)
In-Reply-To: <20140724133823.GA9638@gondor.apana.org.au>
Le 24/07/2014 15:38, Herbert Xu a ?crit :
> On Thu, Jul 24, 2014 at 01:04:55PM +0200, Corentin LABBE wrote:
>> Le 24/07/2014 08:00, Herbert Xu a ?crit :
>>> On Sat, Jul 12, 2014 at 02:59:13PM +0200, LABBE Corentin wrote:
>>>>
>>>> +/* sunxi_hash_init: initialize request context
>>>> + * Activate the SS, and configure it for MD5 or SHA1
>>>> + */
>>>> +int sunxi_hash_init(struct ahash_request *areq)
>>>> +{
>>>> + const char *hash_type;
>>>> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
>>>> + struct sunxi_req_ctx *op = crypto_ahash_ctx(tfm);
>>>> +
>>>> + mutex_lock(&ss->lock);
>>>> +
>>>> + hash_type = crypto_tfm_alg_name(areq->base.tfm);
>>>> +
>>>> + op->byte_count = 0;
>>>> + op->nbwait = 0;
>>>> + op->waitbuf = 0;
>>>> +
>>>> + /* Enable and configure SS for MD5 or SHA1 */
>>>> + if (strcmp(hash_type, "sha1") == 0)
>>>> + op->mode = SS_OP_SHA1;
>>>> + else
>>>> + op->mode = SS_OP_MD5;
>>>> +
>>>> + writel(op->mode | SS_ENABLED, ss->base + SS_CTL);
>>>> + return 0;
>>>
>>> The hash driver is completely broken. You are modifying tfm
>>> ctx data which is shared by all users of a single tfm. So
>>> if two users conduct hashes in parallel they will step all
>>> over each other.
>>
>> So where can I store data for each request ?
>
> Well, first of all you need to stop storing state in the hardware.
> After each operation the hardware may be used by some other user
> for a completely different hash request. So leaving the hash state
> in the hardware is a no-no.
>
> If your hardware supports exporting the hash state then you just
> have to export it after each operation and reimporting before the
> next one.
Even if it is undocumented, the hardware seems to support it.
Since crypto_ahash_ctx is for a tfm, does ahash_request_ctx is the good place to store data ?
(after a call to crypto_ahash_set_reqsize in cra_init)
I have also seen export/import function, does I need to use it ?
>
> If your hardware is incapable of exporting partial hash state then
> you will have to use a software fallback for init/update. If your
> hardware is incapable of importing partial hash state then you will
> also have to do finup/final using a software fallback.
>
> Cheers,
>
WARNING: multiple messages have this Message-ID (diff)
From: Corentin LABBE <clabbe.montjoie@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rdunlap@infradead.org, maxime.ripard@free-electrons.com,
linux@arm.linux.org.uk, davem@davemloft.net,
grant.likely@linaro.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v4 3/3] crypto: Add Allwinner Security System crypto accelerator
Date: Sat, 26 Jul 2014 16:01:26 +0200 [thread overview]
Message-ID: <53D3B4B6.3000100@gmail.com> (raw)
In-Reply-To: <20140724133823.GA9638@gondor.apana.org.au>
Le 24/07/2014 15:38, Herbert Xu a écrit :
> On Thu, Jul 24, 2014 at 01:04:55PM +0200, Corentin LABBE wrote:
>> Le 24/07/2014 08:00, Herbert Xu a écrit :
>>> On Sat, Jul 12, 2014 at 02:59:13PM +0200, LABBE Corentin wrote:
>>>>
>>>> +/* sunxi_hash_init: initialize request context
>>>> + * Activate the SS, and configure it for MD5 or SHA1
>>>> + */
>>>> +int sunxi_hash_init(struct ahash_request *areq)
>>>> +{
>>>> + const char *hash_type;
>>>> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
>>>> + struct sunxi_req_ctx *op = crypto_ahash_ctx(tfm);
>>>> +
>>>> + mutex_lock(&ss->lock);
>>>> +
>>>> + hash_type = crypto_tfm_alg_name(areq->base.tfm);
>>>> +
>>>> + op->byte_count = 0;
>>>> + op->nbwait = 0;
>>>> + op->waitbuf = 0;
>>>> +
>>>> + /* Enable and configure SS for MD5 or SHA1 */
>>>> + if (strcmp(hash_type, "sha1") == 0)
>>>> + op->mode = SS_OP_SHA1;
>>>> + else
>>>> + op->mode = SS_OP_MD5;
>>>> +
>>>> + writel(op->mode | SS_ENABLED, ss->base + SS_CTL);
>>>> + return 0;
>>>
>>> The hash driver is completely broken. You are modifying tfm
>>> ctx data which is shared by all users of a single tfm. So
>>> if two users conduct hashes in parallel they will step all
>>> over each other.
>>
>> So where can I store data for each request ?
>
> Well, first of all you need to stop storing state in the hardware.
> After each operation the hardware may be used by some other user
> for a completely different hash request. So leaving the hash state
> in the hardware is a no-no.
>
> If your hardware supports exporting the hash state then you just
> have to export it after each operation and reimporting before the
> next one.
Even if it is undocumented, the hardware seems to support it.
Since crypto_ahash_ctx is for a tfm, does ahash_request_ctx is the good place to store data ?
(after a call to crypto_ahash_set_reqsize in cra_init)
I have also seen export/import function, does I need to use it ?
>
> If your hardware is incapable of exporting partial hash state then
> you will have to use a software fallback for init/update. If your
> hardware is incapable of importing partial hash state then you will
> also have to do finup/final using a software fallback.
>
> Cheers,
>
next prev parent reply other threads:[~2014-07-26 14:01 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-12 12:59 [PATCH v4] crypto: Add Allwinner Security System crypto accelerator LABBE Corentin
2014-07-12 12:59 ` LABBE Corentin
2014-07-12 12:59 ` [PATCH v4 1/3] ARM: sun7i: dt: Add Security System to A20 SoC DTS LABBE Corentin
2014-07-12 12:59 ` LABBE Corentin
[not found] ` <1405169953-13695-1-git-send-email-clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-12 12:59 ` [PATCH v4 2/3] ARM: sunxi: dt: Add DT bindings documentation for SUNXI Security System LABBE Corentin
2014-07-12 12:59 ` LABBE Corentin
2014-07-12 12:59 ` LABBE Corentin
2014-07-25 10:10 ` Maxime Ripard
2014-07-25 10:10 ` Maxime Ripard
2014-07-12 12:59 ` [PATCH v4 3/3] crypto: Add Allwinner Security System crypto accelerator LABBE Corentin
2014-07-12 12:59 ` LABBE Corentin
2014-07-23 13:16 ` Herbert Xu
2014-07-23 13:16 ` Herbert Xu
[not found] ` <20140723131620.GC29178-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2014-07-23 13:48 ` Maxime Ripard
2014-07-23 13:48 ` Maxime Ripard
2014-07-23 13:48 ` Maxime Ripard
2014-07-23 13:54 ` Herbert Xu
2014-07-23 13:54 ` Herbert Xu
2014-07-23 13:54 ` Herbert Xu
2014-07-24 6:00 ` Herbert Xu
2014-07-24 6:00 ` Herbert Xu
2014-07-24 11:04 ` Corentin LABBE
2014-07-24 11:04 ` Corentin LABBE
2014-07-24 13:38 ` Herbert Xu
2014-07-24 13:38 ` Herbert Xu
[not found] ` <20140724133823.GA9638-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2014-07-26 14:01 ` Corentin LABBE [this message]
2014-07-26 14:01 ` Corentin LABBE
2014-07-26 14:01 ` Corentin LABBE
[not found] ` <53D3B4B6.3000100-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-07-27 14:52 ` Herbert Xu
2014-07-27 14:52 ` Herbert Xu
2014-07-27 14:52 ` Herbert Xu
2014-07-25 11:36 ` Maxime Ripard
2014-07-25 11:36 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53D3B4B6.3000100@gmail.com \
--to=clabbe.montjoie-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.