Hi ,
I am trying to understand Hashing Algorithms implementation in linux kernel .
I am really not sure on how to deal with following scenario.
assume when App1 is in middle of
execution(crypto_ahash_init/update/update...) ,App2 sends a request
may be from another cpu in multi-core system to underlying crypto
driver .
Then essentially input1 has to save its state(intermediate Hash) and
serves App2 request.
App1 ---------> Linux kernel crypto driver
crypto_ahash_init(input1);
crypto_ahash_update(input1);
..................
..................
crypto_ahash_update(input1); // multple Hash requests
..................
..................
crypto_ahash_final()
App2 ---------> Linux kernel crypto driver
crypto_ahash_init(input2);
crypto_ahash_update(input2);
Here in this scenario how to track,save and restore the Hash state for App1 ?
BR,
Srisowj
Hi Markus,
Thanks for the information provided .
But I am still not really sure how does crypto driver keeps track of
the context (intermediate Hash) ,when another application/thread sends
a request ? I think export/import methods are used to export this
intermediate hash to upper layers ,then to import the same when
Needed.
Please can you provide some inputs on the same may be with some open
source references if possible.
BR,
& Srisowj
On Thu, Feb 19, 2015 at 10:20 PM, Markus Stockhausen
<[email protected]> wrote:
> If I understand it correctly each requestor gets its own (multiple)
> contexts. So no need to worry. It will use a different area to store
> intermediate values.
>
> Markus
>
> Am 19.02.2015 17:18 schrieb sri sowj <[email protected]>:
>
> Hi ,
>
> I am trying to understand Hashing Algorithms implementation in linux kernel
> .
>
> I am really not sure on how to deal with following scenario.
>
> assume when App1 is in middle of
> execution(crypto_ahash_init/update/update...) ,App2 sends a request
> may be from another cpu in multi-core system to underlying crypto
> driver .
> Then essentially input1 has to save its state(intermediate Hash) and
> serves App2 request.
>
> App1 ---------> Linux kernel crypto driver
>
> crypto_ahash_init(input1);
> crypto_ahash_update(input1);
> ..................
> ..................
> crypto_ahash_update(input1); // multple Hash requests
> ..................
> ..................
> crypto_ahash_final()
>
>
>
> App2 ---------> Linux kernel crypto driver
>
> crypto_ahash_init(input2);
> crypto_ahash_update(input2);
>
>
> Here in this scenario how to track,save and restore the Hash state for App1
> ?
>
> BR,
> Srisowj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Donnerstag, 19. Februar 2015, 21:48:30 schrieb sri sowj:
Hi sri,
> Hi ,
>
> I am trying to understand Hashing Algorithms implementation in linux kernel
> .
>
> I am really not sure on how to deal with following scenario.
>
> assume when App1 is in middle of
> execution(crypto_ahash_init/update/update...) ,App2 sends a request
> may be from another cpu in multi-core system to underlying crypto
> driver .
> Then essentially input1 has to save its state(intermediate Hash) and
> serves App2 request.
>
> App1 ---------> Linux kernel crypto driver
>
> crypto_ahash_init(input1);
> crypto_ahash_update(input1);
> ..................
> ..................
> crypto_ahash_update(input1); // multple Hash requests
> ..................
> ..................
> crypto_ahash_final()
>
>
>
> App2 ---------> Linux kernel crypto driver
>
> crypto_ahash_init(input2);
> crypto_ahash_update(input2);
>
>
> Here in this scenario how to track,save and restore the Hash state for App1
> ?
The ahash (ablkcipher too) uses kernel threads. Those are scheduled like
normal processes, including the context switching.
>
> BR,
> Srisowj
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ciao
Stephan
Hi Muller ,
Thanks for the information provided.
I am little confused between current scenario (multiple threads will
send multiple requests to crypto H/W) and export/import.
Please can you let me know when export/imports can be used in real time?
I Have seen many references of these method(export/import) in open
source , but not really sure when its being used in real time.
BR,
Srisowj
On Sat, Feb 21, 2015 at 1:07 AM, Stephan Mueller <[email protected]> wrote:
> Am Donnerstag, 19. Februar 2015, 21:48:30 schrieb sri sowj:
>
> Hi sri,
>
>> Hi ,
>>
>> I am trying to understand Hashing Algorithms implementation in linux kernel
>> .
>>
>> I am really not sure on how to deal with following scenario.
>>
>> assume when App1 is in middle of
>> execution(crypto_ahash_init/update/update...) ,App2 sends a request
>> may be from another cpu in multi-core system to underlying crypto
>> driver .
>> Then essentially input1 has to save its state(intermediate Hash) and
>> serves App2 request.
>>
>> App1 ---------> Linux kernel crypto driver
>>
>> crypto_ahash_init(input1);
>> crypto_ahash_update(input1);
>> ..................
>> ..................
>> crypto_ahash_update(input1); // multple Hash requests
>> ..................
>> ..................
>> crypto_ahash_final()
>>
>>
>>
>> App2 ---------> Linux kernel crypto driver
>>
>> crypto_ahash_init(input2);
>> crypto_ahash_update(input2);
>>
>>
>> Here in this scenario how to track,save and restore the Hash state for App1
>> ?
>
> The ahash (ablkcipher too) uses kernel threads. Those are scheduled like
> normal processes, including the context switching.
>>
>> BR,
>> Srisowj
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> Ciao
> Stephan
Am Samstag, 21. Februar 2015, 01:39:23 schrieb sri sowj:
Hi sri,
> Hi Muller ,
>
> Thanks for the information provided.
>
> I am little confused between current scenario (multiple threads will
> send multiple requests to crypto H/W) and export/import.
>
> Please can you let me know when export/imports can be used in real time?
>
> I Have seen many references of these method(export/import) in open
> source , but not really sure when its being used in real time.
>
When you talk about crypto accelerators, then the serialization depends on the
accelerator driver and the properties of the hardware.
For in-CPU accelerators (like AES-NI or z/Series CPACF) where you have one
caller for one hardware instance, every core implements these instructions and
thus, there is no need of serialization. Of course, these cipher instruction
must be atomic instructions to ensure that no serialization is needed (to
protect in case of interrupts).
But for hardware where we only have one hardware component (i.e. 1:n hardware
vs caller), the driver interfacing that driver must ensure serialization. When
you look into those implementations, you see locks or mutexes being used.
> BR,
> Srisowj
>
> On Sat, Feb 21, 2015 at 1:07 AM, Stephan Mueller <[email protected]>
wrote:
> > Am Donnerstag, 19. Februar 2015, 21:48:30 schrieb sri sowj:
> >
> > Hi sri,
> >
> >> Hi ,
> >>
> >> I am trying to understand Hashing Algorithms implementation in linux
> >> kernel
> >> .
> >>
> >> I am really not sure on how to deal with following scenario.
> >>
> >> assume when App1 is in middle of
> >> execution(crypto_ahash_init/update/update...) ,App2 sends a request
> >> may be from another cpu in multi-core system to underlying crypto
> >> driver .
> >> Then essentially input1 has to save its state(intermediate Hash) and
> >> serves App2 request.
> >>
> >> App1 ---------> Linux kernel crypto driver
> >>
> >> crypto_ahash_init(input1);
> >>
> >> crypto_ahash_update(input1);
> >>
> >> ..................
> >> ..................
> >>
> >> crypto_ahash_update(input1); // multple Hash requests
> >>
> >> ..................
> >> ..................
> >>
> >> crypto_ahash_final()
> >>
> >> App2 ---------> Linux kernel crypto driver
> >>
> >> crypto_ahash_init(input2);
> >> crypto_ahash_update(input2);
> >>
> >> Here in this scenario how to track,save and restore the Hash state for
> >> App1
> >> ?
> >
> > The ahash (ablkcipher too) uses kernel threads. Those are scheduled like
> > normal processes, including the context switching.
> >
> >> BR,
> >> Srisowj
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-crypto"
> >> in
> >> the body of a message to [email protected]
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > --
> > Ciao
> > Stephan
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ciao
Stephan