[strongSwan] Charon Core files observed with aes-ni driver.
bhargav p
bhargav.1226 at gmail.com
Tue Nov 4 10:42:43 CET 2014
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 <bhargav.1226 at gmail.com> 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 <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/20141104/f09d0fdf/attachment-0001.html>
More information about the Users
mailing list