[strongSwan] Charon Core files observed with aes-ni driver.

bhargav p bhargav.1226 at gmail.com
Mon Oct 20 14:35:23 CEST 2014


>     I am observering charon generated core files when I configured aes as
an encryption alogorithm.
>
>     aes-ni is enabled on my device.
I seriously doubt that this is a aes-ni-related problem, try running
charon with the environment-variable OPENSSL_ia32cap set, such that
bit #57 is cleared [1] (should be the value ~0x200000000000000).

[Bhargav]  I am not sure, this is aes-ni related problem or not. I have two
machines one with aes-ni and without aes-ni and same strongswan version
[4.3.6 ] and same openssl. And only the difference is aes flag is enabled
/proc/cpuinfo of one machine and in one machine it is not enabled.
I m seeing this crash  where aes is enabled.

I will try running whatever suggested.


>
>     strongswan version I am using is 4.3.6 and openssl version
openssl-1.0.0.
>
>     I ran gdb on the core file, it is pointing to the below point
>
>
>     #4  0x00007fabd3eee1b7 in EVP_CIPHER_CTX_set_key_length
(c=0x7fabcc99e8b0, keylen=16) at evp_enc.c:520
>     520evp_enc.c: No such file or directory.
>     in evp_enc.c
>     (gdb) p *c
>     $1 = {cipher = 0x0, engine = 0x0, encrypt = 1, buf_len = 0, oiv =
'\000' <repeats 15 times>, iv = '\000' <repeats 15 times>, buf = '\000'
<repeats 31 times>, num = 0,
>     app_data = 0x0,
>       key_len = 0, flags = 256, cipher_data = 0x0, final_used = 0,
block_mask = 0, final = '\000' <repeats 31 times>}
A little more context (as in backtrace: '(gdb) help bt') would
certainly help! But I'm guessing it leads somewhere to [2], which
as you can see, calls EVP_CIPHER_CTX_set_key_length, regardless
of EVP_CipherInit_ex's return code. Martin fixed this in [3] which
is first available with strongswan 5.0.2, so maybe you check this
version out.
However: my guess is, that openssl has problems dealing with the
cipher, use gdb to print *this->cipher from openssl_crypt.c to shed
some more light on this.
Btw: which openssl-1.0.0 version are you using: [d-n] are available)?

[Bhargav] And more backtrace:


#4  0x00007fab0ecf61b7 in EVP_CIPHER_CTX_set_key_length (c=0x7fab05xxxxxx0,
keylen=16) at evp_enc.c:520
No locals.
#5  0x00007fab0f24a4ab in crypt (this=0x2626640, data=..., iv=...,
dst=<value optimized out>, enc=1)
    at /strongswan/src/libstrongswan/plugins/openssl/openssl_crypter.c:137
        len = <value optimized out>
        out = 0x2626a70 "\210\360{\017\253\177"
        ctx = {cipher = 0x0, engine = 0x0, encrypt = 1, buf_len = 0, oiv =
'\000' <repeats 15 times>, iv = '\000' <repeats 15 times>, buf = '\000'
<repeats 31 times>, num = 0, app_data = 0x0,
          key_len = 0, flags = 256, cipher_data = 0x0, final_used = 0,
block_mask = 0, final = '\000' <repeats 31 times>}
#6  0x00007fab0f24a5e4 in encrypt (this=0x7fab05fa38b0, data=..., iv=...,
dst=0x40b2)
    at /strongswan/src/libstrongswan/plugins/openssl/openssl_crypter.c:160
No locals.
#7  0x000000000043dfec in encrypt (this=0x2626740)
    at /strongswan/src/charon/encoding/payloads/encryption_payload.c:366
        iv = {ptr = 0x2626620
"\272\262]*\212\306=\313W\347r\031\234D<\034", len = 16}
        padding = {ptr = 0x2625310 "A\255Z`\037JbK\f\272\226", len = 11}
        to_crypt = {ptr = 0x26268d0 "'", len = 192}
        result = {ptr = 0x2626a70 "\210\360{\017\253\177", len = 192}
        rng = <value optimized out>
        block_size = 16

In frame 7 we can see this pointer having something:

(gdb) f 7
#7  0x000000000043dfec in encrypt (this=0x2626740)
    at
/security/strongswan/src/charon/encoding/payloads/encryption_payload.c:366
366 this->crypter->encrypt(this->crypter, to_crypt, iv, &result);

(gdb) p this->crypter
$20 = (crypter_t *) 0x2626640
(gdb) x/10b 0x2626640
0x2626640: -80 -91 36 15 -85 127 0 0
0x2626648: 80 -91

But in frame 6 we can see this beoming NULL,

(gdb) f 6
  0x00007fab0f24a5e4 in encrypt (this=0x7fab05fa38b0, data=..., iv=...,
dst=0x40b2)
(gdb) p *this
$21 = {public = {crypter_interface = {encrypt = 0, decrypt = 0,
get_block_size = 0x1, get_key_size = 0, set_key = 0, destroy = 0}}, key =
{ptr = 0x0, len = 0}, cipher = 0x0}

Here cipher is NULL. Here is my suspicion.

Yes, looks like it is pointing to Martin's fix. But is there something
wrong with openssl when it is initialising with aes-ni driver?

This crash is happening when encrypting the IKE_AAUTH payload.

-Bhargav

On Fri, Oct 17, 2014 at 1:19 AM, Thomas Egerer <hakke_007 at gmx.de> wrote:

> Hi Bhargav,
>
> On 10/16/2014 08:11 PM, bhargav p wrote:
> > Hi,
> >
> > Can someone please reply to the query?
> >
> > On Mon, Oct 13, 2014 at 12:13 PM, bhargav p <bhargav.1226 at gmail.com
> <mailto:bhargav.1226 at gmail.com>> wrote:
> >
> >
> >     Hi,
> >
> >     I am observering charon generated core files when I configured aes
> as an encryption alogorithm.
> >
> >     aes-ni is enabled on my device.
> I seriously doubt that this is a aes-ni-related problem, try running
> charon with the environment-variable OPENSSL_ia32cap set, such that
> bit #57 is cleared [1] (should be the value ~0x200000000000000).
> >
> >     strongswan version I am using is 4.3.6 and openssl version
> openssl-1.0.0.
> >
> >     I ran gdb on the core file, it is pointing to the below point
> >
> >
> >     #4  0x00007fabd3eee1b7 in EVP_CIPHER_CTX_set_key_length
> (c=0x7fabcc99e8b0, keylen=16) at evp_enc.c:520
> >     520evp_enc.c: No such file or directory.
> >     in evp_enc.c
> >     (gdb) p *c
> >     $1 = {cipher = 0x0, engine = 0x0, encrypt = 1, buf_len = 0, oiv =
> '\000' <repeats 15 times>, iv = '\000' <repeats 15 times>, buf = '\000'
> <repeats 31 times>, num = 0,
> >     app_data = 0x0,
> >       key_len = 0, flags = 256, cipher_data = 0x0, final_used = 0,
> block_mask = 0, final = '\000' <repeats 31 times>}
> A little more context (as in backtrace: '(gdb) help bt') would
> certainly help! But I'm guessing it leads somewhere to [2], which
> as you can see, calls EVP_CIPHER_CTX_set_key_length, regardless
> of EVP_CipherInit_ex's return code. Martin fixed this in [3] which
> is first available with strongswan 5.0.2, so maybe you check this
> version out.
> However: my guess is, that openssl has problems dealing with the
> cipher, use gdb to print *this->cipher from openssl_crypt.c to shed
> some more light on this.
> Btw: which openssl-1.0.0 version are you using: [d-n] are available)?
>
> >     cipher is becoming NULL.
> Judging from the code, this is impossible, if EVP_CipherInit_ex has
> been called :/
>
>
> Cheers, let's have a drink now!
> Thomas
>
> [1] https://www.openssl.org/docs/crypto/OPENSSL_ia32cap.html
> [2]
>
> https://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libstrongswan/plugins/openssl/openssl_crypter.c;h=a8923ab56b3f4a3801b905c0a55c7e32d2f509cf;hb=7daf5226b74e14a6e0f1a888b0be26f3d246f9f8#l137
> [1] https://git.strongswan.org/?p=strongswan.git;a=commit;h=e35abbe5
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20141020/78d723e0/attachment.html>


More information about the Users mailing list