Re: kernel tainted while exporting shash context using af_alg interface

[Harsh Jain]

Hi Stephan,

I tried 1 more patch. This time result is correct. Find attached patch
file. Is there any side effect of this patch.


Regards
Harsh Jain

On Mon, Oct 26, 2015 at 11:49 AM, Harsh Jain  wrote:
> Hi Stephan,
>
> I also tried test program in libkcapi and it works. libkcapi opens
> socket of type "hmac(sha1)" .Openssl opens multiple "sha1" type socket
> and uses the partial results to calculate hmac.
>
>  "crypto_ahash_init()" function initialises the *tfm variable in
> crypto_shash structure.It gets called when user calls write() system
> call. To give a try I updated the hash_accept() function and re-run.
> This time kernel didn't crashed but result calculated is wrong.
>
> How accept() sys call decide weather to call alg_accept() or hash_accept()?
>
> Find attached patch and strace.Right now af_alg code is not accessible
> to me. I will share it tomorrow.
>
>
>
> Thanks and Regards
> Harsh jain
>
> On Sun, Oct 25, 2015 at 5:28 PM, Stephan Mueller  wrote:
>> Am Sonntag, 25. Oktober 2015, 11:56:27 schrieb Harsh Jain:
>>
>> Hi Harsh,
>>
>>>Hi,
>>>
>>>
>>>When trying to calculate HMAC(SHA1) with openssl using af-alg engine
>>>kernel crashes.Find below the command used and kernel. I have added
>>>some debug print in logs.
>>>
>>>Command used : ./openssl dgst -engine af_alg -sha1 -hmac "key" r.txt
>>>kernel version : 3.17.8
>>>
>>>Initial Investigation : In shash_desc structure tfm pointer contains
>>>5a5a5a5a5a5a5a5a(invalid pointer), when it triess to reference export
>>>function pointer it crashes. As per my understanding tfm object should
>>>have pointer of memory bloack allocated in
>>>"crypto_init_shash_ops_async" function
>>>
>>>Please give some pointers to debug the issue.Any documentation to
>>>understand the crypto-api code.
>>
>> May I ask you to send 2 things: the source code of the OpenSSL af_alg engine
>> that you use (IIRC it is not included upstream, I want to be sure I used the
>> right one).
>>
>> Further, can you attach an strace of the aforementioned command?
>>
>> Note, I am playing and abusing the AF_ALG interface for quite some time with
>> [1] but I did not come across any issues like the one you describe here.
>>
>> [1] http://www.chronox.de/libkcapi.html
>>
>> Ciao
>> Stephan


algif_hash_2.patch
Description: Binary data

Crypto Fixes for 4.3

[Herbert Xu]

Hi Linus:

This push fixes a problem in the Crypto API that may cause spurious
errors when signals are received by the process that made the orignal
system call into the kernel.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Herbert Xu (1):
  crypto: api - Only abort operations on fatal signal

 crypto/ablkcipher.c  |2 +-
 crypto/algapi.c  |2 +-
 crypto/api.c |6 +++---
 crypto/crypto_user.c |2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

Thanks,
-- 
Email: Herbert Xu 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel tainted while exporting shash context using af_alg interface

[Harsh Jain]

Hi Stephan,

I also tried test program in libkcapi and it works. libkcapi opens
socket of type "hmac(sha1)" .Openssl opens multiple "sha1" type socket
and uses the partial results to calculate hmac.

 "crypto_ahash_init()" function initialises the *tfm variable in
crypto_shash structure.It gets called when user calls write() system
call. To give a try I updated the hash_accept() function and re-run.
This time kernel didn't crashed but result calculated is wrong.

How accept() sys call decide weather to call alg_accept() or hash_accept()?

Find attached patch and strace.Right now af_alg code is not accessible
to me. I will share it tomorrow.



Thanks and Regards
Harsh jain

On Sun, Oct 25, 2015 at 5:28 PM, Stephan Mueller  wrote:
> Am Sonntag, 25. Oktober 2015, 11:56:27 schrieb Harsh Jain:
>
> Hi Harsh,
>
>>Hi,
>>
>>
>>When trying to calculate HMAC(SHA1) with openssl using af-alg engine
>>kernel crashes.Find below the command used and kernel. I have added
>>some debug print in logs.
>>
>>Command used : ./openssl dgst -engine af_alg -sha1 -hmac "key" r.txt
>>kernel version : 3.17.8
>>
>>Initial Investigation : In shash_desc structure tfm pointer contains
>>5a5a5a5a5a5a5a5a(invalid pointer), when it triess to reference export
>>function pointer it crashes. As per my understanding tfm object should
>>have pointer of memory bloack allocated in
>>"crypto_init_shash_ops_async" function
>>
>>Please give some pointers to debug the issue.Any documentation to
>>understand the crypto-api code.
>
> May I ask you to send 2 things: the source code of the OpenSSL af_alg engine
> that you use (IIRC it is not included upstream, I want to be sure I used the
> right one).
>
> Further, can you attach an strace of the aforementioned command?
>
> Note, I am playing and abusing the AF_ALG interface for quite some time with
> [1] but I did not come across any issues like the one you describe here.
>
> [1] http://www.chronox.de/libkcapi.html
>
> Ciao
> Stephan


algif_hash.patch
Description: Binary data


strace.log
Description: Binary data

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Marcel Holtmann]

Hi Stephan,

> This patch set adds the AF_ALG user space API to externalize the
> asymmetric cipher API recently added to the kernel crypto API.
> 
> The patch set is tested with the user space library of libkcapi [1].
> Use [1] test/test.sh for a full test run. The test covers the
> following scenarios:
> 
>   * sendmsg of one IOVEC
> 
>   * sendmsg of 16 IOVECs with non-linear buffer
> 
>   * vmsplice of one IOVEC
> 
>   * vmsplice of 15 IOVECs with non-linear buffer
> 
>   * invoking multiple separate cipher operations with one
> open cipher handle
> 
>   * encryption with private key (using vector from testmgr.h)
> 
>   * encryption with public key (using vector from testmgr.h)
> 
>   * decryption with private key (using vector from testmgr.h)

after having discussions with David Howells and David Woodhouse, I don't think 
we should expose akcipher via AF_ALG at all. I think the akcipher operations 
for sign/verify/encrypt/decrypt should operate on asymmetric keys in the first 
place. With akcipher you are pretty much bound to public and private keys and 
the key is the important part and not the akcipher itself. Especially since we 
want to support private keys in hardware (like TPM for example).

It seems more appropriate to use keyctl to derive the symmetric session key 
from your asymmetric key. And then use the symmetric session key id with 
skcipher via AF_ALG. Especially once symmetric key type has been introduced 
this seems to be trivial then.

I am not really in favor of having two userspace facing APIs for asymmetric 
cipher usage. And we need to have an API that is capable to work with hardware 
keys.

Regards

Marcel

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