Linux-Crypto Archive mirror
 help / color / mirror / Atom feed

From: Kamlesh Gurudasani <kamlesh@ti.com>
To: <herbert@gondor.apana.org.au>, <davem@davemloft.net>,
	<linux-crypto@vger.kernel.org>
Cc: <vigneshr@ti.com>, <j-choudhary@ti.com>
Subject: [RFC] crypto: sa2ul - sha1/sha256/sha512 support
Date: Wed, 22 May 2024 16:42:52 +0530	[thread overview]
Message-ID: <878r02f6bv.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me> (raw)

Hi Herbert,

TI's crypto accelerator SA2UL doesn't support partial hashing (can't
export hash in between) but it does support incremental hashing (can
process multiple updates).

Currently in driver, only digest is being offloaded to hardware.
init + update + final are implemented using software fall back method.

Multiple of our customer wants to use SA2UL for openssl, which basically
ends up calling init + n X update + final, which ends up using software
fallback(CPU) method.

For incremental hasing, we have to keep the FRAG bit set.
For last packet, we have to unset the FRAG bit and then send the last
packet in. But we don't have a way to know if it is last packet.

We can implement update function to offload to HW, and then call
implemented finup for last packet. But this will fail the selftest combo
of init + update + final. If final is called without sending the last
packet with FRAG bit unset, SHA can't be extracted from SA2UL. As we
have no way to know whether it is a last update or not, the last packet
was also sent in with FRAG bit set.

I found a old thread[0] where Tero has tried to do this by appending all the
data from updates in one buffer and dump them in to SA2UL in one shot.
His idea was rejected because

"These states could potentially be placed on the stack so they
must not be large."

But now we know that FRAG bit can be used. The problem of not able to
know which is last packet can be solved if we can have a lag of one
update packet.

As in, the data that came in first update will be stored
in buffer stored in context and, when second update comes, we pass the
first updates data from buffer to SA2UL and stores the data that came in second
update in buffer. This way when final function is being called we
have last packet in global buffer and that can be sent with FRAG bit unset
to get the SHA.

All we need is buffer only big enough to hold the data that can
be MAX size of data that can come in update from AF_ALG or cryptodev.

With this solution, we still can't support intermediate hash, so export
function will not export intermediate hash. But import and export
functions are not marked as mandatory and we don't really need them either.

Let me know if this solution is upstreamable or if you have any other suggestions.

Thanks,
Kamlesh

[0]https://patchwork.kernel.org/project/linux-crypto/patch/20200615071452.25141-4-t-kristo@ti.com/#23454245

next             reply	other threads:[~2024-05-22 11:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-22 11:12 Kamlesh Gurudasani [this message]
2024-05-29  9:41 ` [RFC] crypto: sa2ul - sha1/sha256/sha512 support Herbert Xu
2024-06-05 12:42   ` Kamlesh Gurudasani
2024-06-06  2:01     ` Herbert Xu
2024-06-06 12:03       ` Kamlesh Gurudasani
2024-06-07  9:58         ` Herbert Xu
2024-06-10 13:08           ` Kamlesh Gurudasani
2024-06-11  3:20             ` Herbert Xu

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=878r02f6bv.fsf@kamlesh.i-did-not-set--mail-host-address--so-tickle-me \
    --to=kamlesh@ti.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=j-choudhary@ti.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=vigneshr@ti.com \
    /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

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 read-only IMAP folder(s) and NNTP newsgroup(s).