[RFC] crypto: sa2ul - sha1/sha256/sha512 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxx/#23454245




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux