Re: [Ocf-linux-users] Cryptosoft problem...

[David M. <dav...@mc...>]

Hi Herman,

Thanks for the these.  Both of the changes are in the new version I just
uploaded to sourceforge.

http://sourceforge.net/projects/ocf-linux/files/ocf-linux/20120127/

Let me know if I messed any of it up :-)

Thanks,
Davidm

Jivin Schuurman, Herman lays it down ...
> Hi David,
> 
> It looks like the OCF cryptosoft driver is not terminating scatterlists correctly.  The problem shows up if a crypto API hardware driver relies on sg_next() to return NULL at the end of a scatterlist chain, eventually leading to a bad pointer reference if the end is not marked correctly.
> 
> The following change to crypto/ocf/cryptosoft.c looks like it resolves the problem:
> 
> 	*** crypto/ocf/cryptosoft.c 2011-11-18 16:00:50.399693999 -0600
> 	--- crypto/ocf/cryptosoft.c 2012-01-25 11:45:48.637623644 -0600
> 	***************
> 	*** 814,819 ****
> 	--- 814,820 ----
> 	                     sg_len, offset_in_page(crp->crp_buf + skip));
> 	              sg_num = 1;
> 	       }
> 	+      sg_mark_end(&req->sg[sg_num-1]);
> 	  
> 	       switch (sw->sw_type & SW_TYPE_ALG_AMASK) {
> 
> This marks the last sg entry written with sg_mark_end().
> 
> Best regards,
> 
> Herman Schuurman
> 
> 
> 

Jivin Schuurman, Herman lays it down ...
> Hi David,
> 
> The current version of cryptotest from the crypto-tools-20100325.tar.gz package only tests the sha256_hmac, and not the md5_hmac, sha1_hmac, sha384_hmac, and sha512_hmac (if available).  This happens because the authkey length settings don't match between crypto/ocf/cryptodev.c and cryptotest.c.
> 
> Crypto/ocf/cryptodev.c uses the following settings for authkey, based on the operation (see cryptodev_ioctl()):
> 
>     CRYPTO_MD5_HMAC        16
>     CRYPTO_SHA1_HMAC       20
>     CRYPTO_SHA2_256_HMAC   32
>     CRYPTO_SHA2_384_HMAC   48
>     CRYPTO_SHA2_512_HMAC   64
> 
> Cryptotest.c uses the alg structure table to compute the authkey length:
> 
>     { "md5",            1,    8,    0,    0,        16,    CRYPTO_MD5 },
>     { "md5_hmac",       1,    8,    1,    64,       16,    CRYPTO_MD5_HMAC },
>     { "sha1",           1,    8,    0,    0,        20,    CRYPTO_SHA1 },
>     { "sha1_hmac",      1,    1,    1,    64,       20,    CRYPTO_SHA1_HMAC },
>     { "sha256",         1,    8,    0,    0,        32,    CRYPTO_SHA2_256 },
>     { "sha256_hmac",    1,    1,    1,    64,       32,    CRYPTO_SHA2_256_HMAC },
>     { "sha384",         1,    8,    0,    0,        48,    CRYPTO_SHA2_384 },
>     { "sha384_hmac",    1,    1,    1,    64,       48,    CRYPTO_SHA2_384_HMAC },
>     { "sha512",         1,    8,    0,    0,        64,    CRYPTO_SHA2_512 },
>     { "sha512_hmac",    1,    1,    1,    64,       64,    CRYPTO_SHA2_512_HMAC },
> 
> All _hmac entries show a minkeylen/maxkeylen value of 1/64.  This causes runtest() to pass a keylen of (1+64)/2 = 32, which only works for the sha256_hmac.  Changing the table entries in cryptotest.c to:
> 
>     { "md5",            1,    8,    0,    0,        16,    CRYPTO_MD5 },
>     { "md5_hmac",       1,    8,    16,   16,       16,    CRYPTO_MD5_HMAC },
>     { "sha1",           1,    8,    0,    0,        20,    CRYPTO_SHA1 },
>     { "sha1_hmac",      1,    1,    20,   20,       20,    CRYPTO_SHA1_HMAC },
>     { "sha256",         1,    8,    0,    0,        32,    CRYPTO_SHA2_256 },
>     { "sha256_hmac",    1,    1,    32,   32,       32,    CRYPTO_SHA2_256_HMAC },
>     { "sha384",         1,    8,    0,    0,        48,    CRYPTO_SHA2_384 },
>     { "sha384_hmac",    1,    1,    48,   48,       48,    CRYPTO_SHA2_384_HMAC },
>     { "sha512",         1,    8,    0,    0,        64,    CRYPTO_SHA2_512 },
>     { "sha512_hmac",    1,    1,    64,   64,       64,    CRYPTO_SHA2_512_HMAC },
> 
> allows cryptotest to test the other *_hmacs too.
> 
> Best regards,
> 
> Herman Schuurman
> 
> 
> 


-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org