Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry.Kasatkin]

----- Original message -----
> Hi:
> 
> OK so you did answer my question :)
> 
> Dmitry Kasatkin <dmitry.kasatkin@nokia.com> wrote:
> > 
> > Interesting case with hmac.
> > 
> > return crypto_shash_init(&desc.shash) ?:
> > crypto_shash_update(&desc.shash, ipad, bs) ?:
> > crypto_shash_export(&desc.shash, ipad) ?:
> > crypto_shash_init(&desc.shash) ?:
> > crypto_shash_update(&desc.shash, opad, bs) ?:
> > crypto_shash_export(&desc.shash, opad);
> > 
> > Basically it does not call final.
> > Then call init again.
> > 
> > hw has certain limitation that it requires to process last block with 
> > some bit set.
> > WHen update is called there is no possibility to know that no more 
> > update() will come.
> > So possible last block is stored and then hashed out from the final.
> > 
> > I see that above code will not work with the driver.
> > I wonder how intermediate export/import could be done with omap hw.
> > 
> > But if it's not possible, then why not to have hmac(sha1) as just sw.
> > Anyway hmac should not process as huge amount of data as hash itself.
> > 
> > What is your opinion/advice?
> 
> A sha1-only driver is not very useful since the biggest potential
> user IPsec uses hmac(sha1).
> 
> Is the omap hw documentation available publicly?
> 
> Thanks,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at   http://vger.kernel.org/majordomo-info.html
> 
 
Hi.

Sha1 only is also very useful. We calcluate hashes of all binaries for integrity verification. We do not need hmac there.

But in general it is possible do add algo hmac(sha1) to the driver and implement it internally without import/export.

I have to check on documentation publicity.

Br,
Dmitry

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Thu, Apr 08, 2010 at 06:35:33PM +0200, Dmitry.Kasatkin@nokia.com wrote:
> 
> Sha1 only is also very useful. We calcluate hashes of all binaries for integrity verification. We do not need hmac there.

But do we do that in the Linux kernel?

Of course it would be useful if we had a user-space API, but
that is still on the TODO list.

> But in general it is possible do add algo hmac(sha1) to the driver and implement it internally without import/export.

No we don't want to add hmac to every single driver that does
sha1.  So this would not be a good precedent.  In any case,
some form of import/export must be possible (maybe not in our
current format) because our API requires the ability to perform
a partial update and postpone the finalisation indefinitely.

If you couldn't import/export, that would imply that the hardware
must have infinite memory.

> I have to check on documentation publicity.

Thanks!
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

Hi,

btw. patch to mv_cesa is actually adding hmac to the driver.
How would you comment that?

The same way could be also used here.
I could calc final output with sw.

Any comments?

- Dmitry



On 13/04/10 11:59, ext Herbert Xu wrote:
> On Thu, Apr 08, 2010 at 06:35:33PM +0200, Dmitry.Kasatkin@nokia.com wrote:
>    
>> Sha1 only is also very useful. We calcluate hashes of all binaries for integrity verification. We do not need hmac there.
>>      
> But do we do that in the Linux kernel?
>
> Of course it would be useful if we had a user-space API, but
> that is still on the TODO list.
>
>    
>> But in general it is possible do add algo hmac(sha1) to the driver and implement it internally without import/export.
>>      
> No we don't want to add hmac to every single driver that does
> sha1.  So this would not be a good precedent.  In any case,
> some form of import/export must be possible (maybe not in our
> current format) because our API requires the ability to perform
> a partial update and postpone the finalisation indefinitely.
>
> If you couldn't import/export, that would imply that the hardware
> must have infinite memory.
>
>    
>> I have to check on documentation publicity.
>>      
> Thanks!
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>
> btw. patch to mv_cesa is actually adding hmac to the driver.
> How would you comment that?

AFAICS it's doing HMAC in hardware.  Uri, is that not the case?

> The same way could be also used here.

If your hardware supports HMAC that would definitely be the way
to go.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

Hi

On 13/04/10 13:03, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>    
>> btw. patch to mv_cesa is actually adding hmac to the driver.
>> How would you comment that?
>>      
> AFAICS it's doing HMAC in hardware.  Uri, is that not the case?
>
>    
As I can see from the patch initial vectors calculated with SW shash
Rest is done in hw, basically sha1.

The same can be done with omap driver.
Just in addition to finalize as done in hmac_final().

        crypto_shash_import(desc, opad) ?:
            crypto_shash_finup(desc, out, ds, req->result);


>> The same way could be also used here.
>>      
> If your hardware supports HMAC that would definitely be the way
> to go.
>
> Cheers,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 01:13:47PM +0300, Dmitry Kasatkin wrote:
>
> As I can see from the patch initial vectors calculated with SW shash
> Rest is done in hw, basically sha1.

Ideally that code shouldn't be duplicated either, but honestly
that doesn't matter when it comes to whether the hardware can
do HMAC directly.

You only compute the IVs once for each key, so whether it's done
in software or hardware doesn't matter.

> The same can be done with omap driver.
> Just in addition to finalize as done in hmac_final().

If you do hmac_final in software, then this is no longer a hw
HMAC implementation and we should instead implement an ahash
version of hmac.

The difference here is that ipad/opad is computed only once for
a key, while final happens many times over the lifetime of that
key.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

On 13/04/10 15:02, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 01:13:47PM +0300, Dmitry Kasatkin wrote:
>    
>> As I can see from the patch initial vectors calculated with SW shash
>> Rest is done in hw, basically sha1.
>>      
> Ideally that code shouldn't be duplicated either, but honestly
> that doesn't matter when it comes to whether the hardware can
> do HMAC directly.
>
> You only compute the IVs once for each key, so whether it's done
> in software or hardware doesn't matter.
>
>    
>> The same can be done with omap driver.
>> Just in addition to finalize as done in hmac_final().
>>      
> If you do hmac_final in software, then this is no longer a hw
> HMAC implementation and we should instead implement an ahash
> version of hmac.
>
> The difference here is that ipad/opad is computed only once for
> a key, while final happens many times over the lifetime of that
> key.
>
>    
I do not see your point.
As stated by Uri Simchoni, hw hmac(sha1) in mv_cesa case requires sw 
sha1 driver.
Initial vectors are calculated per key by sw.
So it is no longer hw HMAC implementation.

I just want to understand what make it defferent from mv_cesa if in 
omap-sham case

hash(opad ∥ hash(ipad ∥ message))

I would also:
1. calc hash(opad) using sw, export
2. hash(ipad ∥ message) using hw
3. then import and finup hash from step 1 with results of step 2 (using sw)

What makes it different from mc_cesa case?


> Cheers,
>    
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>
> I would also:
> 1. calc hash(opad) using sw, export
> 2. hash(ipad ∥ message) using hw
> 3. then import and finup hash from step 1 with results of step 2 (using sw)

Step 3 is the problem.  If you perform step 3 in software then
there is no point in exporting a hmac(sha1) object.

We should instead add ahash support to hmac and use that.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Uri Simchoni]

Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.

On 4/13/2010 5:45 PM, Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>>
>> I would also:
>> 1. calc hash(opad) using sw, export
>> 2. hash(ipad ∥ message) using hw
>> 3. then import and finup hash from step 1 with results of step 2 (using sw)
> 
> Step 3 is the problem.  If you perform step 3 in software then
> there is no point in exporting a hmac(sha1) object.
> 
> We should instead add ahash support to hmac and use that.
> 
> Cheers,

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

On 13/04/10 18:16, ext Uri Simchoni wrote:
> Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.
>
>    
Yes. that is exactly what happens in hw - it is much slower.
And I do not see any problems as well with finishing it with sw.


> On 4/13/2010 5:45 PM, Herbert Xu wrote:
>    
>> On Tue, Apr 13, 2010 at 04:00:11PM +0300, Dmitry Kasatkin wrote:
>>      
>>> I would also:
>>> 1. calc hash(opad) using sw, export
>>> 2. hash(ipad ∥ message) using hw
>>> 3. then import and finup hash from step 1 with results of step 2 (using sw)
>>>        
>> Step 3 is the problem.  If you perform step 3 in software then
>> there is no point in exporting a hmac(sha1) object.
>>
>> We should instead add ahash support to hmac and use that.
>>
>> Cheers,
>>      
>    
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 06:21:44PM +0300, Dmitry Kasatkin wrote:
>
>
> On 13/04/10 18:16, ext Uri Simchoni wrote:
>> Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.
>>
>>    
> Yes. that is exactly what happens in hw - it is much slower.
> And I do not see any problems as well with finishing it with sw.

I never said that you can't do it in software.  I just don't
want every driver to write its own copy of hmac in software.

If you're going to do it in software, then let's make an ahash
version of hmac.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

On 14/04/10 03:44, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 06:21:44PM +0300, Dmitry Kasatkin wrote:
>    
>>
>> On 13/04/10 18:16, ext Uri Simchoni wrote:
>>      
>>> Doing step 3 using sw is probably faster than by hw (because it's short and avoid all the hw setup), so the suggested approach is probably faster than generic async hmac.
>>>
>>>
>>>        
>> Yes. that is exactly what happens in hw - it is much slower.
>> And I do not see any problems as well with finishing it with sw.
>>      
> I never said that you can't do it in software.  I just don't
> want every driver to write its own copy of hmac in software.
>
>    
I understand that it is better to have more "generic" approach and not 
duplicate that.
I am not objecting that.

The key point is that we use HW accelerators to get speedup, release CPU 
for something else and reduce power consumption (if possible and 
specific hw does it more energy efficiently).

Base on above facts hw drivers need to make certain optimization.
And that optimization often does not fit well to the "generic" way.

Like just with import/export.
Problems for hw:

1. To have a good performance with DMA we need to have large buffer.
     Not just 64 bytes block. state becomes large

2. supporting concurrent requests means switching HW state and it takes 
a time.

All that burden significantly slowdown hw acceleration and increase CPU 
load.

I guess my points are understandable.

thanks
> If you're going to do it in software, then let's make an ahash
> version of hmac.
>
> Cheers,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Wed, Apr 14, 2010 at 09:37:47AM +0300, Dmitry Kasatkin wrote:
>
> Like just with import/export.
> Problems for hw:
>
> 1. To have a good performance with DMA we need to have large buffer.
>     Not just 64 bytes block. state becomes large

Sure.  But it shouldn't be up to the driver to merge operations.
Higher layers (either the end-user or the crypto API) should perform
merging.

We don't put request merging into storage drivers for a reason.

> 2. supporting concurrent requests means switching HW state and it takes  
> a time.

Well that's just the way it is.  I'm not saying that it's going
to occur frequently, but if it does, you need to support it.

> All that burden significantly slowdown hw acceleration and increase CPU  
> load.
>
> I guess my points are understandable.

I understand your concerns, but these are really limitations
common to all off-chip acceleration.  If you have to write drivers
for them, then you'll have to deal with these issues.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

On 14/04/10 09:44, ext Herbert Xu wrote:
> On Wed, Apr 14, 2010 at 09:37:47AM +0300, Dmitry Kasatkin wrote:
>    
>> Like just with import/export.
>> Problems for hw:
>>
>> 1. To have a good performance with DMA we need to have large buffer.
>>      Not just 64 bytes block. state becomes large
>>      
> Sure.  But it shouldn't be up to the driver to merge operations.
> Higher layers (either the end-user or the crypto API) should perform
> merging.
>
>    
What do you mean by "merge operation".
request merging?

> We don't put request merging into storage drivers for a reason.
>
>    
>> 2. supporting concurrent requests means switching HW state and it takes
>> a time.
>>      
> Well that's just the way it is.  I'm not saying that it's going
> to occur frequently, but if it does, you need to support it.
>
>    
>> All that burden significantly slowdown hw acceleration and increase CPU
>> load.
>>
>> I guess my points are understandable.
>>      
> I understand your concerns, but these are really limitations
> common to all off-chip acceleration.  If you have to write drivers
> for them, then you'll have to deal with these issues.
>
> Cheers,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Wed, Apr 14, 2010 at 09:51:22AM +0300, Dmitry Kasatkin wrote:
>
> What do you mean by "merge operation".
> request merging?

By buffering user data, you're in essence merging requests.

I have no objections to doing that, but let's not do it in every
driver.

Of course, the ultimate solution is for the end-user to produce
requests that do not need merging.  So when considering this we
need to be aware of what users are being targeted.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

Hi,

crypto_ahash_update()
crypto_ahash_dinup()
crypto_ahash_final()

obviously might need to return -EINPROGRESS

but can
crypto_ahash_init(req)

be synchronous?

Or it could also return EINPROGRESS, though not sense.

- Dmitry


On 14/04/10 09:55, ext Herbert Xu wrote:
> On Wed, Apr 14, 2010 at 09:51:22AM +0300, Dmitry Kasatkin wrote:
>    
>> What do you mean by "merge operation".
>> request merging?
>>      
> By buffering user data, you're in essence merging requests.
>
> I have no objections to doing that, but let's not do it in every
> driver.
>
> Of course, the ultimate solution is for the end-user to produce
> requests that do not need merging.  So when considering this we
> need to be aware of what users are being targeted.
>
> Thanks,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Fri, Apr 16, 2010 at 10:44:37AM +0300, Dmitry Kasatkin wrote:
> Hi,
>
> crypto_ahash_update()
> crypto_ahash_dinup()
> crypto_ahash_final()
>
> obviously might need to return -EINPROGRESS
>
> but can
> crypto_ahash_init(req)
>
> be synchronous?
>
> Or it could also return EINPROGRESS, though not sense.

crypto_ahash_init is allowed to return EINPROGRESS, but it certainly
doesn't *have* to be asynchronous.  Most hardware implementations
should be able to do it synchronously by duplicating a precomputed
initial state.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

Btw.

But anyway hmac does not support ahash now. right?
So the only way currently is to add to the driver.


On 13/04/10 13:03, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>    
>> btw. patch to mv_cesa is actually adding hmac to the driver.
>> How would you comment that?
>>      
> AFAICS it's doing HMAC in hardware.  Uri, is that not the case?
>
>    
>> The same way could be also used here.
>>      
> If your hardware supports HMAC that would definitely be the way
> to go.
>
> Cheers,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Uri Simchoni]

The Marvell CESA needs some software assistance in doing HMAC - the inner and outer blocks need
to be prepared and hashed (partial hash). The hash results are fed into the hardware and the hardware uses it
as IVs and does the two hash operations. So in effect the HW hmac(sha1) driver needs software sha1 driver.

Note, however, that the above calculation is not per-request, it is per setkey operation. The IVs are stored in the tfm.

I hope that clears things with respect to the mv_cesa driver.

On 4/13/2010 1:15 PM, Dmitry Kasatkin wrote:
> Btw.
> 
> But anyway hmac does not support ahash now. right?
> So the only way currently is to add to the driver.
> 
> 
> On 13/04/10 13:03, ext Herbert Xu wrote:
>> On Tue, Apr 13, 2010 at 12:39:55PM +0300, Dmitry Kasatkin wrote:
>>   
>>> btw. patch to mv_cesa is actually adding hmac to the driver.
>>> How would you comment that?
>>>      
>> AFAICS it's doing HMAC in hardware.  Uri, is that not the case?
>>
>>   
>>> The same way could be also used here.
>>>      
>> If your hardware supports HMAC that would definitely be the way
>> to go.
>>
>> Cheers,
>>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
>
> But anyway hmac does not support ahash now. right?
> So the only way currently is to add to the driver.

No the only way is to add an ahash version of hmac.

Anyway, the fact that you can't easily implement import/export
is not just a question of supporting hmac.  It is in fact a sign
that your driver breaks the crypto API.

The fundamental requirement for the ahash interface is that you
must be able to launch multiple operations, which means that all
state must be stored in the request and not held in hardware
(except as a cache).

IOW, you must be able to support

	crypto_ahash_update(&reqa);

	...

	crypto_ahash_update(&reqb);

	...

	ahash_request_set_crypt(&reqa, ...);
	crypto_ahash_finup(&reqa);

	...

	ahash_request_set_crypt(&reqb, ...);
	crypto_ahash_finup(&reqb);

AFAICS your driver cannot do this correctly in its current form.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

Please see inline. Nice to clarify it.

On 13/04/10 15:10, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
>    
>> But anyway hmac does not support ahash now. right?
>> So the only way currently is to add to the driver.
>>      
> No the only way is to add an ahash version of hmac.
>
> Anyway, the fact that you can't easily implement import/export
> is not just a question of supporting hmac.  It is in fact a sign
> that your driver breaks the crypto API.
>
> The fundamental requirement for the ahash interface is that you
> must be able to launch multiple operations, which means that all
> state must be stored in the request and not held in hardware
> (except as a cache).
>
> IOW, you must be able to support
>
> 	crypto_ahash_update(&reqa);
>
> 	...
>
> 	crypto_ahash_update(&reqb);
>
> 	...
>
> 	ahash_request_set_crypt(&reqa, ...);
> 	crypto_ahash_finup(&reqa);
>
> 	...
>
> 	ahash_request_set_crypt(&reqb, ...);
> 	crypto_ahash_finup(&reqb);
>
> AFAICS your driver cannot do this correctly in its current form.
>
>    
Well it can... if reqa occupied hw all other requests will fallback to 
sw sha1.

But if to do only hw and to follow above algorithm then it is necessary 
to remove shash support completely from the driver.
And have a queue as I have with aes driver..
err = ablkcipher_enqueue_request(&dd->queue, req);

I see there is ahash_enqueue_request() which is in 
crypto/internal/hash.h and NEVER called.

Also in one of your earlier emails you said that it is not possible to 
call crypto_ahash_update() before completion.
But with having a queue it does not really matter.
Possible to queue several update request from the same tfm.

The only need to wait_for_completion is to export/get results...

Can you confirm my understanding?

Thanks



Well. not like that.

> Thanks,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

Also one more question.

can reqa and reqb could come from the same tfm as well?

thanks

On 13/04/10 16:44, Kasatkin Dmitry (Nokia-D/Helsinki) wrote:
> Please see inline. Nice to clarify it.
>
> On 13/04/10 15:10, ext Herbert Xu wrote:
>    
>> On Tue, Apr 13, 2010 at 01:15:34PM +0300, Dmitry Kasatkin wrote:
>>
>>      
>>> But anyway hmac does not support ahash now. right?
>>> So the only way currently is to add to the driver.
>>>
>>>        
>> No the only way is to add an ahash version of hmac.
>>
>> Anyway, the fact that you can't easily implement import/export
>> is not just a question of supporting hmac.  It is in fact a sign
>> that your driver breaks the crypto API.
>>
>> The fundamental requirement for the ahash interface is that you
>> must be able to launch multiple operations, which means that all
>> state must be stored in the request and not held in hardware
>> (except as a cache).
>>
>> IOW, you must be able to support
>>
>> 	crypto_ahash_update(&reqa);
>>
>> 	...
>>
>> 	crypto_ahash_update(&reqb);
>>
>> 	...
>>
>> 	ahash_request_set_crypt(&reqa, ...);
>> 	crypto_ahash_finup(&reqa);
>>
>> 	...
>>
>> 	ahash_request_set_crypt(&reqb, ...);
>> 	crypto_ahash_finup(&reqb);
>>
>> AFAICS your driver cannot do this correctly in its current form.
>>
>>
>>      
> Well it can... if reqa occupied hw all other requests will fallback to
> sw sha1.
>
> But if to do only hw and to follow above algorithm then it is necessary
> to remove shash support completely from the driver.
> And have a queue as I have with aes driver..
> err = ablkcipher_enqueue_request(&dd->queue, req);
>
> I see there is ahash_enqueue_request() which is in
> crypto/internal/hash.h and NEVER called.
>
> Also in one of your earlier emails you said that it is not possible to
> call crypto_ahash_update() before completion.
> But with having a queue it does not really matter.
> Possible to queue several update request from the same tfm.
>
> The only need to wait_for_completion is to export/get results...
>
> Can you confirm my understanding?
>
> Thanks
>
>
>
> Well. not like that.
>
>    
>> Thanks,
>>
>>      
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 05:36:40PM +0300, Dmitry Kasatkin wrote:
> Also one more question.
>
> can reqa and reqb could come from the same tfm as well?

Yes of course.

Two packets coming from different CPUs going to through the same
IPsec SA for instance.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

On 13/04/10 17:42, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 05:36:40PM +0300, Dmitry Kasatkin wrote:
>    
>> Also one more question.
>>
>> can reqa and reqb could come from the same tfm as well?
>>      
> Yes of course.
>
> Two packets coming from different CPUs going to through the same
> IPsec SA for instance.
>
>    
Then state must be kept in req ctx, not tfm ctx.
Right?

Then when handling different request HW must be re-initialized.
If handling the same request then no need to reinitialize.

Also not possible to call update(reqa) until previous completed.
Otherwise it will mess up data in reqa.

Thanks

> Cheers,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 06:33:59PM +0300, Dmitry Kasatkin wrote:
>
> Then state must be kept in req ctx, not tfm ctx.
> Right?

Correct, the same thing applies to both shash and ahash.

> Then when handling different request HW must be re-initialized.
> If handling the same request then no need to reinitialize.

Yes, you're allowed to cache state in the HW so that two requests
in a row that use the same state can avoid reinitialisation.

> Also not possible to call update(reqa) until previous completed.
> Otherwise it will mess up data in reqa.

That is up to the user to enforce.  You just need to ensure that
the hardware remains in a sane state even if the user screws up.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 04:44:35PM +0300, Dmitry Kasatkin wrote:
>
> Well it can... if reqa occupied hw all other requests will fallback to  
> sw sha1.

That is unacceptable.  If we had a user-space API that would
mean a single request can tie up the hardware indefinitely.

If your hardware is not able to produce a non-finalised hash,
then you should only do finup/final in hardware, and use a software
fallback to implement the rest.

If your hardware is also not able to accept an initial state,
then the only thing you can implement is digest.  The rest would
have to fall back to software.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

About import/export.

The problem with HW is that it always handles 64 byte blocks except last 
one.
So until finup/final it is not known if it is the last data. So some 
buffer is kept in context.

With DMA it is very inefficient to have small buffer.
I use page 4k for that.
So after a certain update there is a data in the cache.

Doing export means that we need to get out intermediate hash and that 
buffer.

Any suggestion?

Thanks


On 13/04/10 17:48, ext Herbert Xu wrote:
> On Tue, Apr 13, 2010 at 04:44:35PM +0300, Dmitry Kasatkin wrote:
>    
>> Well it can... if reqa occupied hw all other requests will fallback to
>> sw sha1.
>>      
> That is unacceptable.  If we had a user-space API that would
> mean a single request can tie up the hardware indefinitely.
>
> If your hardware is not able to produce a non-finalised hash,
> then you should only do finup/final in hardware, and use a software
> fallback to implement the rest.
>
>    
> If your hardware is also not able to accept an initial state,
> then the only thing you can implement is digest.  The rest would
> have to fall back to software.
>
> Cheers,
>    

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Apr 13, 2010 at 06:48:42PM +0300, Dmitry Kasatkin wrote:
>
> About import/export.
>
> The problem with HW is that it always handles 64 byte blocks except last  
> one.
> So until finup/final it is not known if it is the last data. So some  
> buffer is kept in context.
>
> With DMA it is very inefficient to have small buffer.
> I use page 4k for that.
> So after a certain update there is a data in the cache.
>
> Doing export means that we need to get out intermediate hash and that  
> buffer.
>
> Any suggestion?

There is no need to buffer extra data in the driver.  If we need
to do that that should be done in the upper layer.

So my suggestion would be to feed everything you get in update to
the hardware immediately, unless of course if it's less than a
single block.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
was not ported to new crypto APIs and removed from the source tree.

This driver implements async and sync crypto API.

It still contains pr_debug() for debugging purpose.
Will be remove for integration.

Dmitry Kasatkin (2):
  sec: omap sha1 & md5 driver
  sec: Makefile/Kconfig update for omap sha1 md5 driver

 drivers/crypto/Kconfig         |    9 +
 drivers/crypto/Makefile        |    2 +
 drivers/crypto/omap-sha1-md5.c | 1449 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 1460 insertions(+), 0 deletions(-)
 create mode 100644 drivers/crypto/omap-sha1-md5.c

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
> was not ported to new crypto APIs and removed from the source tree.
> 
> This driver implements async and sync crypto API.
> 
> It still contains pr_debug() for debugging purpose.
> Will be remove for integration.
> 
> Dmitry Kasatkin (2):
>   sec: omap sha1 & md5 driver
>   sec: Makefile/Kconfig update for omap sha1 md5 driver

It looks good to me as far as the Crypto API is concerned.

My only question is what's your plan with respect to HMAC? If
you're going to do it in hardware then it's fine as it is.

Otherwise you need to implement export/import and we also need
to add ahash support to hmac.c.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

On 23/03/10 13:32, ext Herbert Xu wrote:
> On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
>    
>> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
>> was not ported to new crypto APIs and removed from the source tree.
>>
>> This driver implements async and sync crypto API.
>>
>> It still contains pr_debug() for debugging purpose.
>> Will be remove for integration.
>>
>> Dmitry Kasatkin (2):
>>    sec: omap sha1&  md5 driver
>>    sec: Makefile/Kconfig update for omap sha1 md5 driver
>>      
> It looks good to me as far as the Crypto API is concerned.
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
>
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.
>
> Thanks,
>    

Hello,

Thanks for looking to it.

No hw is not doing hmac.
I need to look to this then.

Will comeback in a while.

- Dmitry

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Dmitry Kasatkin]

On 23/03/10 13:32, ext Herbert Xu wrote:
> On Wed, Mar 17, 2010 at 03:12:49PM +0200, Dmitry Kasatkin wrote:
>    
>> Earlier kernel contained omap sha1 and md5 driver, which was not maintained,
>> was not ported to new crypto APIs and removed from the source tree.
>>
>> This driver implements async and sync crypto API.
>>
>> It still contains pr_debug() for debugging purpose.
>> Will be remove for integration.
>>
>> Dmitry Kasatkin (2):
>>    sec: omap sha1&  md5 driver
>>    sec: Makefile/Kconfig update for omap sha1 md5 driver
>>      
> It looks good to me as far as the Crypto API is concerned.
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
>
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.
>
> Thanks,
>    

Hello.

Interesting case with hmac.

     return crypto_shash_init(&desc.shash) ?:
            crypto_shash_update(&desc.shash, ipad, bs) ?:
            crypto_shash_export(&desc.shash, ipad) ?:
            crypto_shash_init(&desc.shash) ?:
            crypto_shash_update(&desc.shash, opad, bs) ?:
            crypto_shash_export(&desc.shash, opad);

Basically it does not call final.
Then call init again.

hw has certain limitation that it requires to process last block with 
some bit set.
WHen update is called there is no possibility to know that no more 
update() will come.
So possible last block is stored and then hashed out from the final.

I see that above code will not work with the driver.
I wonder how intermediate export/import could be done with omap hw.

But if it's not possible, then why not to have hmac(sha1) as just sw.
Anyway hmac should not process as huge amount of data as hash itself.

What is your opinion/advice?

Thank you
- Dmitry

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

Hi:

OK so you did answer my question :)

Dmitry Kasatkin <dmitry.kasatkin@nokia.com> wrote:
>
> Interesting case with hmac.
> 
>     return crypto_shash_init(&desc.shash) ?:
>            crypto_shash_update(&desc.shash, ipad, bs) ?:
>            crypto_shash_export(&desc.shash, ipad) ?:
>            crypto_shash_init(&desc.shash) ?:
>            crypto_shash_update(&desc.shash, opad, bs) ?:
>            crypto_shash_export(&desc.shash, opad);
> 
> Basically it does not call final.
> Then call init again.
> 
> hw has certain limitation that it requires to process last block with 
> some bit set.
> WHen update is called there is no possibility to know that no more 
> update() will come.
> So possible last block is stored and then hashed out from the final.
> 
> I see that above code will not work with the driver.
> I wonder how intermediate export/import could be done with omap hw.
> 
> But if it's not possible, then why not to have hmac(sha1) as just sw.
> Anyway hmac should not process as huge amount of data as hash itself.
>
> What is your opinion/advice?

A sha1-only driver is not very useful since the biggest potential
user IPsec uses hmac(sha1).

Is the omap hw documentation available publicly?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 0/2] crypto: omap-sha1-md5: OMAP3 SHA1 & MD5 driver

[Herbert Xu]

On Tue, Mar 23, 2010 at 07:32:39PM +0800, Herbert Xu wrote:
>
> My only question is what's your plan with respect to HMAC? If
> you're going to do it in hardware then it's fine as it is.
> 
> Otherwise you need to implement export/import and we also need
> to add ahash support to hmac.c.

Dmitry, did you answer this before or did it get lost in the mail :)

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt