From: Tero Kristo <t-kristo@ti.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: <davem@davemloft.net>, <linux-crypto@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <j-keerthy@ti.com>
Subject: Re: [PATCHv4 3/7] crypto: sa2ul: add sha1/sha256/sha512 support
Date: Fri, 26 Jun 2020 12:15:42 +0300 [thread overview]
Message-ID: <2a89ea86-3b9e-06b5-fa8e-9dc6e5ad9aeb@ti.com> (raw)
In-Reply-To: <20200626043155.GA2683@gondor.apana.org.au>
On 26/06/2020 07:31, Herbert Xu wrote:
> On Mon, Jun 15, 2020 at 10:14:48AM +0300, Tero Kristo wrote:
>>
>> +static int sa_sha_update(struct ahash_request *req)
>> +{
>> + struct sa_sha_req_ctx *rctx = ahash_request_ctx(req);
>> + struct scatterlist *sg;
>> + void *buf;
>> + int pages;
>> + struct page *pg;
>> +
>> + if (!req->nbytes)
>> + return 0;
>> +
>> + if (rctx->buf_free >= req->nbytes) {
>> + pg = sg_page(rctx->sg_next);
>> + buf = kmap_atomic(pg);
>> + scatterwalk_map_and_copy(buf + rctx->offset, req->src, 0,
>> + req->nbytes, 0);
>> + kunmap_atomic(buf);
>> + rctx->buf_free -= req->nbytes;
>> + rctx->sg_next->length += req->nbytes;
>> + rctx->offset += req->nbytes;
>> + } else {
>> + pages = get_order(req->nbytes);
>> + buf = (void *)__get_free_pages(GFP_ATOMIC, pages);
>> + if (!buf)
>> + return -ENOMEM;
>> +
>> + sg = kzalloc(sizeof(*sg) * 2, GFP_KERNEL);
>> + if (!sg)
>> + return -ENOMEM;
>> +
>> + sg_init_table(sg, 1);
>> + sg_set_buf(sg, buf, req->nbytes);
>> + scatterwalk_map_and_copy(buf, req->src, 0, req->nbytes, 0);
>> +
>> + rctx->buf_free = (PAGE_SIZE << pages) - req->nbytes;
>> +
>> + if (rctx->sg_next) {
>> + sg_unmark_end(rctx->sg_next);
>> + sg_chain(rctx->sg_next, 2, sg);
>> + } else {
>> + rctx->src = sg;
>> + }
>> +
>> + rctx->sg_next = sg;
>> + rctx->src_nents++;
>> +
>> + rctx->offset = req->nbytes;
>> + }
>> +
>> + rctx->len += req->nbytes;
>> +
>> + return 0;
>> +}
>
> This is not how it's supposed to work. To support the partial
> hashing interface, you must actually hash the data and not just
> save it in your context. Otherwise your export is completely
> meaningless.
I have been experimenting with an alternate approach, where I have a
small buffer within the context, this would be more like the way other
drivers do this. If the buffer is closed before running out of space, I
can push this to be processed by HW, otherwise I must fallback to SW.
Does this sound like a better approach?
> If your hardware cannot export partially hashed state, then you
> should use a software fallback for everything but digest.
Yea, HW can't support partial hashes.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
next prev parent reply other threads:[~2020-06-26 9:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-15 7:14 [PATCHv4 0/7] crypto: sa2ul support for TI K3 SoCs Tero Kristo
2020-06-15 7:14 ` [PATCHv4 1/7] dt-bindings: crypto: Add TI SA2UL crypto accelerator documentation Tero Kristo
2020-06-15 7:14 ` [PATCHv4 2/7] crypto: sa2ul: Add crypto driver Tero Kristo
2020-06-15 7:14 ` [PATCHv4 3/7] crypto: sa2ul: add sha1/sha256/sha512 support Tero Kristo
2020-06-26 4:31 ` Herbert Xu
2020-06-26 9:15 ` Tero Kristo [this message]
2020-06-30 4:49 ` Herbert Xu
2020-06-30 7:20 ` Tero Kristo
2020-06-30 7:46 ` Herbert Xu
2020-06-30 7:52 ` Tero Kristo
2020-06-30 7:54 ` Herbert Xu
2020-06-30 7:58 ` Tero Kristo
2020-06-30 7:59 ` Herbert Xu
2020-06-30 8:17 ` Tero Kristo
2020-06-15 7:14 ` [PATCHv4 4/7] crypto: sa2ul: Add AEAD algorithm support Tero Kristo
2020-06-15 7:14 ` [PATCHv4 5/7] crypto: sa2ul: add device links to child devices Tero Kristo
2020-06-15 7:14 ` [PATCHv4 6/7] arm64: dts: ti: k3-am6: Add crypto accelarator node Tero Kristo
2020-06-15 7:14 ` [PATCHv4 7/7] arm64: dts: ti: k3-j721e-main: Add crypto accelerator node Tero Kristo
2020-06-15 18:20 ` [PATCHv4 0/7] crypto: sa2ul support for TI K3 SoCs Eric Biggers
2020-06-16 4:24 ` Tero Kristo
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=2a89ea86-3b9e-06b5-fa8e-9dc6e5ad9aeb@ti.com \
--to=t-kristo@ti.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=j-keerthy@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).