Hi, On further investigation came to know that, crash is happening because openssl initialisation with aes-ni is failing.
Found the same from the link [1][2] After changing the openssl code, now I am not seeing the crash. Now my question, is it really required to use aes-ni during tunnel establishment time. Becasue the messages exchanged during tunnel establishment are not many, we will not see any performance impact if you use aes-ni. Is there any way to avoid charon from using aes-ni through openssl? -Bhargav [1] https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/590639 [2] http://rt.openssl.org/Ticket/Display.html?id=2305&user=guest&pass=guest On Mon, Oct 20, 2014 at 6:05 PM, bhargav p <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] >> https://lists.strongswan.org/mailman/listinfo/users >> > > > >
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
