On Tue, Jul 11, 2017 at 10:52 AM, Kamil Konieczny
<k.koniec...@partner.samsung.com> wrote:
> Hi,
> I am writing crypto driver for hash MD5/SHA1/SHA256 on Exynos 4412,
> and I am facing some (minor?) difficulties.
> In old days, hadware (HW) can only do basic hash block operation,
> so at the end it needed to finalize hash, and driver need to
> write some bits into buffer to get message hash. Time passes,
> and hardware (HW) was designed with improved cappabilities,
> so it can add itself bits after message and calculate hash,
> it can stop then export state, import and resume,
> but ... it can not process null-length (or zero-length) ending.
> So there is no more final method.
> It must be feeded with at least one message byte to produce hash.
> One more constrain is to process data in constant-sized chunks,
> here it is 64 bytes, the same as for AES block,
> i.e. it cannot stop and export state while in middle of block,
> example - if we feed 16 bytes, we must then feed 48 bytes
> to stop, but ideally we should feed it always 64 bytes.

> Some crypto drivers with similar problem(s):
> omap-sham.c - no final and blocksize needed,
> broadcom bcm/spu.c - no final,
> ccp/ccp-crypto-sha.c - no final,
> nx/nx-sha256.c - blocksize needed,
> One more thing - in algorithm description for methods:
> final, finup, update, digest, export, import
> there is note that finup is for those hardware
> that cannot do final, but again,
> it looks like crypto framework is ignoring that and every finup
> is translated into "update, final".
> HW driver will do opposite - it will translate final into finup.
> From this follows that for every such HW crypto drivers authors
> duplicate code for keeping at least blocksize cache of message.
> One more point - use of block size in algo structure.
> It is for informing framework about HW limitation,
> but seems to be ignored again...
> Any suggestions ?
> Can i keep some bytes unfeeded from ahash_request
> and return -EINPROGRESS ?
> Should i set timer and copy rest bytes after some timeout,
> where no more requests are incoming ? Or not ? cause it is
> async mode ?
> can i wait for more requests for processing waiting one ?

Your two constraints are actually inter-related -

If you can only feed the HW a constant size chunk, than indeed need to
keey bytes fed
to the driver the are below the chunk size in a software buffer, but
than you need the final()
method to feed these bytes (padded as needed) to the HW if they are
the last bytes


Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Reply via email to