Re: kernel tainted while exporting shash context using af_alg interface

[Harsh Jain]

Hi,

I tried patch on my setup and its working fine.
Thanks Stephan, Herbert for your support.

Regards
Harsh Jain

On Fri, Oct 30, 2015 at 4:40 PM, Stephan Mueller  wrote:
> Am Freitag, 30. Oktober 2015, 14:02:27 schrieb Harsh Jain:
>
> Hi Harsh,
>
>>Hi Stephan,
>>
>>If we add sendmsg() in between 2 accept calls then the setkey problem
>>will happen?
>>
>>handle->opfd = accept(handle->tfmfd, NULL, 0);
>>sendmsg()
>>handle->opfd = accept(handle->opfd, NULL, 0);
>>sendmsg()
>>handle->opfd = accept(handle->opfd, NULL, 0);
>
> Without testing, I would very much expect that, because the setkey does not
> apply to the subordinate tfm.
>>
>>If yes, Then may be it is expected behavior and user is supposed to
>>set the key explicitly with some other system call.Why I am saying
>>this is. I remember somewhere in kernel code I read some comment
>>related to setkey operations.
>
> I would like to wait for Herbert to chime in here on how he thinks this would
> work.
>>
>>In that case my patch should work. 1 doubt I have related to patch is
>>do I need to set "ctx->more" =1 after initialisation.
>>
>>Correct me If I am wrong.
>>
>>
>>Thanks for your support.
>>
>>
>>regards
>>Harsh Jain
>>
>>On Wed, Oct 28, 2015 at 4:53 PM, Stephan Mueller  wrote:
>>> Am Mittwoch, 28. Oktober 2015, 16:24:34 schrieb Harsh Jain:
>>>
>>> Hi Harsh,
>>>
Hi Stephan,

I tried your patch on my machine. Kernel is not crashing. The openssl
break with this. Can you share HMAC program which you are suspecting
it will not work or do you already have some test written in
libkcapi/test.sh which will fail.

>>> See comments above test/kcapi-main.c:cavs_hash
>>>
>>>  * HMAC command line invocation:
>>>  * $ ./kcapi -x 3 -c "hmac(sha1)" -k
>>>  6e77ebd479da794707bc6cde3694f552ea892dab
>>>
>>> -p
>>> 31b62a797adbff6b8a358d2b5206e01fee079de8cdfc4695138bba163b4efbf30127343e7fd
>>> 4fbc696c3d38d8f27f57c024b5056f726ceeb4c31d98e57751ec8cbe8904ee0f9b031ae6a0c
>>> 55da5e062475b3d7832191d4057643ef5fa446801d59a04693e573a8159cd2416b7bd39c7f0
>>> fe63c599365e04d596c05736beaab58>
>>>  * 7f204ea665666f5bd2b370e546d1b408005e4d85
>>>
>>> To do that, apply your patch and then
>>>
>>> 1. open lib/kcapi-kernel-if.c and change line 567 from
>>>
>>> handle->opfd = accept(handle->tfmfd, NULL, 0);
>>>
>>>
>>> to
>>>
>>> handle->opfd = accept(handle->tfmfd, NULL, 0);
>>> handle->opfd = accept(handle->opfd, NULL, 0);
>>> handle->opfd = accept(handle->opfd, NULL, 0);
>>> handle->opfd = accept(handle->opfd, NULL, 0);
>>> handle->opfd = accept(handle->opfd, NULL, 0);
>>>
>>> You will see that the hash commands will pass, the HMAC fails
>>>
>>> Without your patch, the kernel crashes (same as with your OpenSSL code).
>>>
>>> The reason is that setkey is applied on the TFM that is not conveyed to the
>>> subsequent TFMs generated with new accepts.
>>>
Regards
Harsh Jain

On Wed, Oct 28, 2015 at 6:25 AM, Stephan Mueller 
> wrote:
> Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
>
> Hi Harsh,
>
>> However, any error in user space should not crash the kernel. So, a fix
>> should be done. But I think your code is not correct as it solidifies a
>> broken user space code.
>
> After thinking a bit again, I think your approach is correct after all. I
> was able to reproduce the crash by simply adding more accept calls to my
> test code. And I can confirm that your patch works, for hashes.
>
> *BUT* it does NOT work for HMAC as the key is set on the TFM and the
> subsequent accepts do not transport the key. Albeit your code prevents
> the
> kernel from crashing, the HMAC calculation will be done with an empty key
> as
> the setkey operation does not reach the TFM handle in the subordinate
> accept() call.
>
> So, I would think that the second accept is simply broken, for HMAC at
> least.
>
> Herbert, what is the purpose of that subordinate accept that is
> implemented
> with hash_accept? As this is broken for HMACs, should it be removed
> entirely?
>
> --
> Ciao
> Stephan

--
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

>>> Ciao
>>> Stephan
>
>
> Ciao
> Stephan
--
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,

If we add sendmsg() in between 2 accept calls then the setkey problem
will happen?

handle->opfd = accept(handle->tfmfd, NULL, 0);
sendmsg()
handle->opfd = accept(handle->opfd, NULL, 0);
sendmsg()
handle->opfd = accept(handle->opfd, NULL, 0);

If yes, Then may be it is expected behavior and user is supposed to
set the key explicitly with some other system call.Why I am saying
this is. I remember somewhere in kernel code I read some comment
related to setkey operations.

In that case my patch should work. 1 doubt I have related to patch is
do I need to set "ctx->more" =1 after initialisation.

Correct me If I am wrong.


Thanks for your support.


regards
Harsh Jain

On Wed, Oct 28, 2015 at 4:53 PM, Stephan Mueller  wrote:
> Am Mittwoch, 28. Oktober 2015, 16:24:34 schrieb Harsh Jain:
>
> Hi Harsh,
>
>>Hi Stephan,
>>
>>I tried your patch on my machine. Kernel is not crashing. The openssl
>>break with this. Can you share HMAC program which you are suspecting
>>it will not work or do you already have some test written in
>>libkcapi/test.sh which will fail.
>
> See comments above test/kcapi-main.c:cavs_hash
>
>  * HMAC command line invocation:
>  * $ ./kcapi -x 3 -c "hmac(sha1)" -k 6e77ebd479da794707bc6cde3694f552ea892dab
> -p
> 31b62a797adbff6b8a358d2b5206e01fee079de8cdfc4695138bba163b4efbf30127343e7fd4fbc696c3d38d8f27f57c024b5056f726ceeb4c31d98e57751ec8cbe8904ee0f9b031ae6a0c55da5e062475b3d7832191d4057643ef5fa446801d59a04693e573a8159cd2416b7bd39c7f0fe63c599365e04d596c05736beaab58
>  * 7f204ea665666f5bd2b370e546d1b408005e4d85
>
> To do that, apply your patch and then
>
> 1. open lib/kcapi-kernel-if.c and change line 567 from
>
> handle->opfd = accept(handle->tfmfd, NULL, 0);
>
>
> to
>
> handle->opfd = accept(handle->tfmfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
> handle->opfd = accept(handle->opfd, NULL, 0);
>
> You will see that the hash commands will pass, the HMAC fails
>
> Without your patch, the kernel crashes (same as with your OpenSSL code).
>
> The reason is that setkey is applied on the TFM that is not conveyed to the
> subsequent TFMs generated with new accepts.
>>
>>
>>Regards
>>Harsh Jain
>>
>>On Wed, Oct 28, 2015 at 6:25 AM, Stephan Mueller  wrote:
>>> Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
>>>
>>> Hi Harsh,
>>>
 However, any error in user space should not crash the kernel. So, a fix
 should be done. But I think your code is not correct as it solidifies a
 broken user space code.
>>>
>>> After thinking a bit again, I think your approach is correct after all. I
>>> was able to reproduce the crash by simply adding more accept calls to my
>>> test code. And I can confirm that your patch works, for hashes.
>>>
>>> *BUT* it does NOT work for HMAC as the key is set on the TFM and the
>>> subsequent accepts do not transport the key. Albeit your code prevents the
>>> kernel from crashing, the HMAC calculation will be done with an empty key
>>> as
>>> the setkey operation does not reach the TFM handle in the subordinate
>>> accept() call.
>>>
>>> So, I would think that the second accept is simply broken, for HMAC at
>>> least.
>>>
>>> Herbert, what is the purpose of that subordinate accept that is implemented
>>> with hash_accept? As this is broken for HMACs, should it be removed
>>> entirely?
>>>
>>> --
>>> Ciao
>>> Stephan
>>
>>--
>>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
>
>
> Ciao
> Stephan
--
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

[Stephan Mueller]

Am Freitag, 30. Oktober 2015, 14:02:27 schrieb Harsh Jain:

Hi Harsh,

>Hi Stephan,
>
>If we add sendmsg() in between 2 accept calls then the setkey problem
>will happen?
>
>handle->opfd = accept(handle->tfmfd, NULL, 0);
>sendmsg()
>handle->opfd = accept(handle->opfd, NULL, 0);
>sendmsg()
>handle->opfd = accept(handle->opfd, NULL, 0);

Without testing, I would very much expect that, because the setkey does not 
apply to the subordinate tfm.
>
>If yes, Then may be it is expected behavior and user is supposed to
>set the key explicitly with some other system call.Why I am saying
>this is. I remember somewhere in kernel code I read some comment
>related to setkey operations.

I would like to wait for Herbert to chime in here on how he thinks this would 
work.
>
>In that case my patch should work. 1 doubt I have related to patch is
>do I need to set "ctx->more" =1 after initialisation.
>
>Correct me If I am wrong.
>
>
>Thanks for your support.
>
>
>regards
>Harsh Jain
>
>On Wed, Oct 28, 2015 at 4:53 PM, Stephan Mueller  wrote:
>> Am Mittwoch, 28. Oktober 2015, 16:24:34 schrieb Harsh Jain:
>> 
>> Hi Harsh,
>> 
>>>Hi Stephan,
>>>
>>>I tried your patch on my machine. Kernel is not crashing. The openssl
>>>break with this. Can you share HMAC program which you are suspecting
>>>it will not work or do you already have some test written in
>>>libkcapi/test.sh which will fail.
>>>
>> See comments above test/kcapi-main.c:cavs_hash
>> 
>>  * HMAC command line invocation:
>>  * $ ./kcapi -x 3 -c "hmac(sha1)" -k
>>  6e77ebd479da794707bc6cde3694f552ea892dab
>> 
>> -p
>> 31b62a797adbff6b8a358d2b5206e01fee079de8cdfc4695138bba163b4efbf30127343e7fd
>> 4fbc696c3d38d8f27f57c024b5056f726ceeb4c31d98e57751ec8cbe8904ee0f9b031ae6a0c
>> 55da5e062475b3d7832191d4057643ef5fa446801d59a04693e573a8159cd2416b7bd39c7f0
>> fe63c599365e04d596c05736beaab58> 
>>  * 7f204ea665666f5bd2b370e546d1b408005e4d85
>> 
>> To do that, apply your patch and then
>> 
>> 1. open lib/kcapi-kernel-if.c and change line 567 from
>> 
>> handle->opfd = accept(handle->tfmfd, NULL, 0);
>> 
>> 
>> to
>> 
>> handle->opfd = accept(handle->tfmfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> handle->opfd = accept(handle->opfd, NULL, 0);
>> 
>> You will see that the hash commands will pass, the HMAC fails
>> 
>> Without your patch, the kernel crashes (same as with your OpenSSL code).
>> 
>> The reason is that setkey is applied on the TFM that is not conveyed to the
>> subsequent TFMs generated with new accepts.
>> 
>>>Regards
>>>Harsh Jain
>>>
>>>On Wed, Oct 28, 2015 at 6:25 AM, Stephan Mueller  
wrote:
 Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
 
 Hi Harsh,
 
> However, any error in user space should not crash the kernel. So, a fix
> should be done. But I think your code is not correct as it solidifies a
> broken user space code.
 
 After thinking a bit again, I think your approach is correct after all. I
 was able to reproduce the crash by simply adding more accept calls to my
 test code. And I can confirm that your patch works, for hashes.
 
 *BUT* it does NOT work for HMAC as the key is set on the TFM and the
 subsequent accepts do not transport the key. Albeit your code prevents
 the
 kernel from crashing, the HMAC calculation will be done with an empty key
 as
 the setkey operation does not reach the TFM handle in the subordinate
 accept() call.
 
 So, I would think that the second accept is simply broken, for HMAC at
 least.
 
 Herbert, what is the purpose of that subordinate accept that is
 implemented
 with hash_accept? As this is broken for HMACs, should it be removed
 entirely?
 
 --
 Ciao
 Stephan
>>>
>>>--
>>>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
>>>
>> Ciao
>> Stephan


Ciao
Stephan
--
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

[Stephan Mueller]

Am Mittwoch, 28. Oktober 2015, 16:24:34 schrieb Harsh Jain:

Hi Harsh,

>Hi Stephan,
>
>I tried your patch on my machine. Kernel is not crashing. The openssl
>break with this. Can you share HMAC program which you are suspecting
>it will not work or do you already have some test written in
>libkcapi/test.sh which will fail.

See comments above test/kcapi-main.c:cavs_hash

 * HMAC command line invocation:
 * $ ./kcapi -x 3 -c "hmac(sha1)" -k 6e77ebd479da794707bc6cde3694f552ea892dab 
-p  
31b62a797adbff6b8a358d2b5206e01fee079de8cdfc4695138bba163b4efbf30127343e7fd4fbc696c3d38d8f27f57c024b5056f726ceeb4c31d98e57751ec8cbe8904ee0f9b031ae6a0c55da5e062475b3d7832191d4057643ef5fa446801d59a04693e573a8159cd2416b7bd39c7f0fe63c599365e04d596c05736beaab58
 * 7f204ea665666f5bd2b370e546d1b408005e4d85

To do that, apply your patch and then

1. open lib/kcapi-kernel-if.c and change line 567 from

handle->opfd = accept(handle->tfmfd, NULL, 0);


to

handle->opfd = accept(handle->tfmfd, NULL, 0);
handle->opfd = accept(handle->opfd, NULL, 0);
handle->opfd = accept(handle->opfd, NULL, 0);
handle->opfd = accept(handle->opfd, NULL, 0);
handle->opfd = accept(handle->opfd, NULL, 0);

You will see that the hash commands will pass, the HMAC fails

Without your patch, the kernel crashes (same as with your OpenSSL code).

The reason is that setkey is applied on the TFM that is not conveyed to the 
subsequent TFMs generated with new accepts.
>
>
>Regards
>Harsh Jain
>
>On Wed, Oct 28, 2015 at 6:25 AM, Stephan Mueller  wrote:
>> Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
>> 
>> Hi Harsh,
>> 
>>> However, any error in user space should not crash the kernel. So, a fix
>>> should be done. But I think your code is not correct as it solidifies a
>>> broken user space code.
>> 
>> After thinking a bit again, I think your approach is correct after all. I
>> was able to reproduce the crash by simply adding more accept calls to my
>> test code. And I can confirm that your patch works, for hashes.
>> 
>> *BUT* it does NOT work for HMAC as the key is set on the TFM and the
>> subsequent accepts do not transport the key. Albeit your code prevents the
>> kernel from crashing, the HMAC calculation will be done with an empty key
>> as
>> the setkey operation does not reach the TFM handle in the subordinate
>> accept() call.
>> 
>> So, I would think that the second accept is simply broken, for HMAC at
>> least.
>> 
>> Herbert, what is the purpose of that subordinate accept that is implemented
>> with hash_accept? As this is broken for HMACs, should it be removed
>> entirely?
>> 
>> --
>> Ciao
>> Stephan
>
>--
>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


Ciao
Stephan
--
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 tried your patch on my machine. Kernel is not crashing. The openssl
break with this. Can you share HMAC program which you are suspecting
it will not work or do you already have some test written in
libkcapi/test.sh which will fail.


Regards
Harsh Jain

On Wed, Oct 28, 2015 at 6:25 AM, Stephan Mueller  wrote:
> Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
>
> Hi Harsh,
>
>>
>>
>> However, any error in user space should not crash the kernel. So, a fix
>> should be done. But I think your code is not correct as it solidifies a
>> broken user space code.
>
> After thinking a bit again, I think your approach is correct after all. I was
> able to reproduce the crash by simply adding more accept calls to my test
> code. And I can confirm that your patch works, for hashes.
>
> *BUT* it does NOT work for HMAC as the key is set on the TFM and the
> subsequent accepts do not transport the key. Albeit your code prevents the
> kernel from crashing, the HMAC calculation will be done with an empty key as
> the setkey operation does not reach the TFM handle in the subordinate accept()
> call.
>
> So, I would think that the second accept is simply broken, for HMAC at least.
>
> Herbert, what is the purpose of that subordinate accept that is implemented
> with hash_accept? As this is broken for HMACs, should it be removed entirely?
>
> --
> Ciao
> Stephan
--
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

[Stephan Mueller]

Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:

Hi Harsh,

> 
> 
> However, any error in user space should not crash the kernel. So, a fix
> should be done. But I think your code is not correct as it solidifies a
> broken user space code.

After thinking a bit again, I think your approach is correct after all. I was 
able to reproduce the crash by simply adding more accept calls to my test 
code. And I can confirm that your patch works, for hashes.

*BUT* it does NOT work for HMAC as the key is set on the TFM and the 
subsequent accepts do not transport the key. Albeit your code prevents the 
kernel from crashing, the HMAC calculation will be done with an empty key as 
the setkey operation does not reach the TFM handle in the subordinate accept() 
call.

So, I would think that the second accept is simply broken, for HMAC at least.

Herbert, what is the purpose of that subordinate accept that is implemented 
with hash_accept? As this is broken for HMACs, should it be removed entirely?

-- 
Ciao
Stephan
--
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

[Stephan Mueller]

Am Montag, 26. Oktober 2015, 14:51:01 schrieb Harsh Jain:

Hi Harsh,

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

The strace is enlightening.

The user space code does an accept on an already accepted FD

It seems your user space does something like:

socket()
fd = bind()
fd1 = accept(fd)
fd2 = accept(fd1)
fd3 = accept(fd2)
...

That is an error in the user space code. The correct way would be like the 
code in [1] with all the lines until the line 553 (the code afterwards is for 
vmsplice).

So, the code goes like that:

tfmfd = socket()
bind(tfmfd)
opfd = accept(tfmfd);

>From now on, you use opfd for all sendmsg/recvmsg operations.


However, any error in user space should not crash the kernel. So, a fix should 
be done. But I think your code is not correct as it solidifies a broken user 
space code.

I would rather think the following patch should be added to prevent the oops. 
At least for me, multiple accepts does not crash the kernel. Can you please 
test whether this patch ensures you kernel stays sane?

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 1396ad0..785df23 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -183,6 +183,9 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
struct hash_ctx *ctx2;
int err;
 
+   if (!ctx->more)
+   return -EINVAL;
+
err = crypto_ahash_export(req, state);
if (err)
return err;


[1] 
https://github.com/smuellerDD/libkcapi/blob/master/lib/kcapi-kernel-if.c#L534


-- 
Ciao
Stephan
--
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 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

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

kernel tainted while exporting shash context using af_alg interface

[Harsh Jain]

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.

Kernel logs:


[ 3190.053499] Harsh : crypto_ahash_export
[ 3190.053499]  crypto_ahash_reqtfm
[ 3190.053500] req->base.tfm  880193478ec8
[ 3190.053500] __crypto_ahash_cast=req->base.tfm  880193478e80
[ 3190.053501] ahash_request_ctx{req} 8800362ebb98
[ 3190.053501] crypto_shash_alg entered
[ 3190.053502] crypto_shash_alg TFM  5a5a5a5a5a5a5a5a
[ 3190.053502] crypto_shash_alg TFM Base 5a5a5a5a5a5a5a62
[ 3190.053507] general protection fault:  [#1] SMP
[ 3190.053509] Modules linked in: coretemp kvm_intel kvm crc32c_intel
iTCO_wdt iTCO_vendor_support ppdev parport_pc parport i2c_i801 lpc_ich
microcode i2c_core serio_raw mfd_core tpm_infineon pcspkr shpchp
ioatdma i7core_edac edac_core dca acpi_cpufreq uinput xfs libcrc32c
exportfs sd_mod sr_mod crc_t10dif crct10dif_common cdrom ata_generic
pata_acpi e1000e ptp ata_piix mptsas scsi_transport_sas mptscsih
mptbase dm_mirror dm_region_hash dm_log dm_mod ipv6 autofs4
[ 3190.053527] CPU: 1 PID: 3043 Comm: openssl Not tainted 3.17.8_harsh #39
[ 3190.053528] Hardware name: Supermicro X8ST3/X8ST3, BIOS 2.0a   11/28/2012
[ 3190.053529] task: 88019866e2d0 ti: 8800d71e4000 task.ti:
8800d71e4000
[ 3190.053530] RIP: 0010:[]  []
shash_async_export+0x5e/0x90
[ 3190.053533] RSP: 0018:8800d71e7de8  EFLAGS: 00010282
[ 3190.053533] RAX: 002a RBX: 5a5a5a5a5a5a5a5a RCX: 0006
[ 3190.053534] RDX:  RSI: 0246 RDI: 88019fc2c130
[ 3190.053535] RBP: 8800d71e7e00 R08: 0400 R09: 81db9f64
[ 3190.053536] R10: 0ced R11: 0cec R12: 8800362ebb98
[ 3190.053536] R13: 8800d71e7e10 R14: 8800d74bfcc0 R15: 8800362ebb48
[ 3190.053537] FS:  77fe1740() GS:88019fc2()
knlGS:
[ 3190.053538] CS:  0010 DS:  ES:  CR0: 80050033
[ 3190.053539] CR2: 01c3baf8 CR3: daa8b000 CR4: 07e0
[ 3190.053540] Stack:
[ 3190.053540]  8800362eb800 880193478ec8 8800d61b7800
8800d71e7e98
[ 3190.053542]  81295adc 815c3d53 0020
8800d71e7e70
[ 3190.053543]  8800d71e7e30 811b5fab 880193478ec8
81ad4cd0
[ 3190.053545] Call Trace:
[ 3190.053547]  [] hash_accept+0x13c/0x250
[ 3190.053548]  [] ? printk+0x54/0x56
[ 3190.053549]  [] ? alloc_file+0x1b/0xc0
[ 3190.053550]  [] ? hash_accept+0x85/0x250
[ 3190.053552]  [] SYSC_accept4+0xf4/0x200
[ 3190.053553]  [] ? vfs_write+0x15c/0x1f0
[ 3190.053555]  [] SyS_accept+0x10/0x20
[ 3190.053556]  [] system_call_fastpath+0x16/0x1b
[ 3190.053557] Code: 81 31 c0 e8 54 01 35 00 48 c7 c7 6e 61 82 81 31
c0 48 89 de e8 43 01 35 00 48 8d 73 08 48 c7 c7 e8 bd 82 81 31 c0 e8
31 01 35 00 <48> 8b 73 58 48 c7 c7 08 be 82 81 31 c0 e8 1f 01 35 00 48
8b 43
[ 3190.053575] RIP  [] shash_async_export+0x5e/0x90
[ 3190.053577]  RSP 
[ 3190.053578] ---[ end trace d9701f2848d12eb5 ]---
--
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

[Stephan Mueller]

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
--
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