Hello,
Today, the talitos driver dma maps/unmaps context and keys at every
single request.
I'm looking at doing the dma mapping at hash init and doing unmapping at
final/finup/digest
However, I'm wondering how to manage hash exports and imports. I was
initially thinking about doing a dma_sync_for_cpu() before any export
and a dma_sync_for_device() after any export, but that supposes that the
dma area is already mapped, which means that we have done the init and
not yet done a final/finup/digest.
I'm a bit sceptic when reading the following text in include/crypto/hash.h :
@export: Export partial state of the transformation. This function dumps the
* entire state of the ongoing transformation into a provided block of
* data so it can be @import 'ed back later on. This is useful in case
* you want to save partial result of the transformation after
* processing certain amount of data and reload this partial result
* multiple times later on for multiple re-use
Does it mean that import may be called in lieu of hash init, or is hash
init always called before doing an import ?
Thanks
Christophe
On Tue, Sep 26, 2017 at 12:36 PM, Christophe LEROY
<[email protected]> wrote:
> Hello,
>
> Today, the talitos driver dma maps/unmaps context and keys at every single
> request.
> I'm looking at doing the dma mapping at hash init and doing unmapping at
> final/finup/digest
>
> However, I'm wondering how to manage hash exports and imports. I was
> initially thinking about doing a dma_sync_for_cpu() before any export and a
> dma_sync_for_device() after any export, but that supposes that the dma area
> is already mapped, which means that we have done the init and not yet done a
> final/finup/digest.
>
> I'm a bit sceptic when reading the following text in include/crypto/hash.h :
>
> @export: Export partial state of the transformation. This function dumps the
> * entire state of the ongoing transformation into a provided block
> of
> * data so it can be @import 'ed back later on. This is useful in
> case
> * you want to save partial result of the transformation after
> * processing certain amount of data and reload this partial result
> * multiple times later on for multiple re-use
>
>
> Does it mean that import may be called in lieu of hash init, or is hash init
> always called before doing an import ?
>
I believe import is called in lieu of init.
See the example is testmgr.c here:
http://elixir.free-electrons.com/linux/latest/source
import is called on a freshly allocated request (save for set_crypt
and set_callback), followed by
a call to update.
Gilad
> Thanks
> Christophe
--
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
On 26.09.2017 12:34, Gilad Ben-Yossef wrote:
> On Tue, Sep 26, 2017 at 12:36 PM, Christophe LEROY
> <[email protected]> wrote:
>> Hello,
>>
>> Today, the talitos driver dma maps/unmaps context and keys at every single
>> request.
>> I'm looking at doing the dma mapping at hash init and doing unmapping at
>> final/finup/digest
>>
>> However, I'm wondering how to manage hash exports and imports. I was
>> initially thinking about doing a dma_sync_for_cpu() before any export and a
>> dma_sync_for_device() after any export, but that supposes that the dma area
>> is already mapped, which means that we have done the init and not yet done a
>> final/finup/digest.
>>
>> I'm a bit sceptic when reading the following text in include/crypto/hash.h :
>>
>> @export: Export partial state of the transformation. This function dumps the
>> * entire state of the ongoing transformation into a provided block
>> of
>> * data so it can be @import 'ed back later on. This is useful in
>> case
>> * you want to save partial result of the transformation after
>> * processing certain amount of data and reload this partial result
>> * multiple times later on for multiple re-use
>>
>>
>> Does it mean that import may be called in lieu of hash init, or is hash init
>> always called before doing an import ?
>>
>
> I believe import is called in lieu of init.
>
> See the example is testmgr.c here:
> http://elixir.free-electrons.com/linux/latest/source
>
> import is called on a freshly allocated request (save for set_crypt
> and set_callback), followed by
> a call to update.
Both import()/export() are synchronous op, this means they are not allowed
to return -EINPROGRESS nor call complete().
Can import() be called without _any_ init(), for example
after reboot of machine ? Is following scenario valid:
init(), update() 0 or more times, export(),
save exported data to pernament storage
reboot machine
load crypto driver, import() saved state ?
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
On Tue, Sep 26, 2017 at 01:09:05PM +0200, Kamil Konieczny wrote:
>
> Can import() be called without _any_ init(), for example
> after reboot of machine ? Is following scenario valid:
Of course it can. import must restore the state of the request
to that at the time when export was called.
import does not need to be called after init. init simply resets
the hash state for new update/final calls.
> init(), update() 0 or more times, export(),
> save exported data to pernament storage
> reboot machine
> load crypto driver, import() saved state ?
Yes this must be supported.
Basically after any update call is complete (you've called the
completion function), you should be able to call export and
completely extract the partial (as opposed to finalised) hash
state.
Remember we need to support an arbitrarily large number of
concurrent hashing operations. So you cannot keep a hash state
in hardware indefinitely just because the user has not called
finalize on it.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Le 27/09/2017 à 11:08, Herbert Xu a écrit :
> On Tue, Sep 26, 2017 at 01:09:05PM +0200, Kamil Konieczny wrote:
>>
>> Can import() be called without _any_ init(), for example
>> after reboot of machine ? Is following scenario valid:
>
> Of course it can. import must restore the state of the request
> to that at the time when export was called.
>
> import does not need to be called after init. init simply resets
> the hash state for new update/final calls.
>
>> init(), update() 0 or more times, export(),
>> save exported data to pernament storage
>> reboot machine
>> load crypto driver, import() saved state ?
>
> Yes this must be supported.
>
> Basically after any update call is complete (you've called the
> completion function), you should be able to call export and
> completely extract the partial (as opposed to finalised) hash
> state.
Can we consider that once an export has been done, no new update call
will be performed prior to doing an init or an import ? Or should it be
possible to continue with an update or a final/finup call after an export ?
>
> Remember we need to support an arbitrarily large number of
> concurrent hashing operations. So you cannot keep a hash state
> in hardware indefinitely just because the user has not called
> finalize on it.
>
> Cheers,
>
Christophe
On Wed, Sep 27, 2017 at 04:59:56PM +0200, Christophe LEROY wrote:
>
> Can we consider that once an export has been done, no new update call will
> be performed prior to doing an init or an import ? Or should it be possible
> to continue with an update or a final/finup call after an export ?
No export should not affect the ability to perform subsequent
update/finalize calls. IOW it should be a read-only operation
as far as the hash state is concerned.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On 27.09.2017 11:08, Herbert Xu wrote:
> On Tue, Sep 26, 2017 at 01:09:05PM +0200, Kamil Konieczny wrote:
>>
>> Can import() be called without _any_ init(), for example
>> after reboot of machine ? Is following scenario valid:
>
> Of course it can. import must restore the state of the request
> to that at the time when export was called.
>
> import does not need to be called after init. init simply resets
> the hash state for new update/final calls.
> [...]
I have more questions, this time about HMAC export/import.
In doc, there is stated that key can be copied into context transformation.
Should .export copy request context _and_ key used ? Or not ?
When processing requests, can I assume the key in transformation is const until .final ?
Is is possible to have okey derived from different key then ikey ? I think not.
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
On Fri, Nov 24, 2017 at 02:35:04PM +0100, Kamil Konieczny wrote:
>
> I have more questions, this time about HMAC export/import.
> In doc, there is stated that key can be copied into context transformation.
>
> Should .export copy request context _and_ key used ? Or not ?
The key is stored in the tfm so export does not need to touch the
key. However, sometimes the key is naturally embedded in the hash
state too, e.g., with hmac, in that case it would make sense for
export to copy it as part of the hash state.
> When processing requests, can I assume the key in transformation is const until .final ?
Yes you may.
> Is is possible to have okey derived from different key then ikey ? I think not.
We do not need to support that case. If the user changes the
key mid-stream it results in undefined behaviour. However,
the code should not crash though.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt