Summary: | dev-libs/libgcrypt-1.5.0-r2 - aes-ni segfaults | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | [OLD] Library | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | david+gentoo.org, tomwij |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build log |
Description
Toralf Förster
2012-11-10 09:15:24 UTC
Well, it seems to be rather a problem with libgrypt - update from 1.4.x to 1.5 ?? : tfoerste@n22 ~ $ cat devel/gdb_pgp.config set args --armor --recipient Grendelsen --encrypt --sign text tfoerste@n22 ~ $ rm -f text.sc; gdb -x ~/devel/gdb_pgp.config gpg GNU gdb (Gentoo 7.4.1 p2) 7.4.1 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /usr/bin/gpg...Reading symbols from /usr/lib/debug/usr/bin/gpg2.debug...done. done. (gdb) run Starting program: /usr/bin/gpg --armor --recipient Grendelsen --encrypt --sign text warning: Could not load shared library symbols for linux-gate.so.1. Do you need "set solib-search-path" or "set sysroot"? gpg: enabled debug flags: memstat trust extprog assuan You need a passphrase to unlock the secret key for user: "Toralf Förster <toralf.foerster@gmx.de>" 1024-bit DSA key, ID 7DB69DA3, created 2004-08-14 gpg: DBG: connection to agent established File `text.asc' exists. Overwrite? (y/N) y Program received signal SIGSEGV, Segmentation fault. 0xb7f42fdd in do_aesni_enc_aligned ( a=0xb7f7c8f8 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>, b=0xbfffe520 "", ctx=0xbfffe334) at rijndael.c:710 710 rijndael.c: No such file or directory. (gdb) bt #0 0xb7f42fdd in do_aesni_enc_aligned ( a=0xb7f7c8f8 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>, b=0xbfffe520 "", ctx=0xbfffe334) at rijndael.c:710 #1 do_aesni (ctx=0xbfffe334, decrypt_flag=0, bx=0xbfffe520 "", ax=0xb7f7c8f8 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>) at rijndael.c:1132 #2 0xb7f4329e in rijndael_encrypt ( a=0xb7f7c8f8 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>, b=0xbfffe520 "", context=0xbfffe334) at rijndael.c:1155 #3 rijndael_encrypt (context=0xbfffe334, b=0xbfffe520 "", a=0xb7f7c8f8 "\001K\257\"x\246\235\063\035Q\200\020\066C\351\232gC\303\321Q\232\264\362͚x\253\t\245\021\275]\036\362\r\316ּ\274\022\023\032\307\305G\210\252\b\016\225\027\353\026wq\232\317r\200\206\004", <incomplete sequence \343>) at rijndael.c:1138 #4 0xb7f4389c in selftest_basic_128 () at rijndael.c:1660 #5 0xb7f4340f in selftest () at rijndael.c:1749 #6 do_setkey (keylen=32, key=0xb7fd2064 "\377\002\204Ϻ\213ʢ̊\275\347\343q\305\301\226\252\225a\260\271#7\211\333\001", ctx=0xb7fd2880) at rijndael.c:209 #7 rijndael_setkey (context=0xb7fd2880, key=0xb7fd2064 "\377\002\204Ϻ\213ʢ̊\275\347\343q\305\301\226\252\225a\260\271#7\211\333\001", keylen=32) at rijndael.c:444 #8 0xb7f27517 in cipher_setkey (c=0xb7fd2800, key=<optimized out>, keylen=32) at cipher.c:900 #9 0xb7f1d644 in gcry_cipher_setkey (hd=0xb7fd2800, key=0xb7fd2064, keylen=32) at visibility.c:521 #10 0x08062057 in make_session_key (dek=0xb7fd2050) at seskey.c:53 #11 0x0808785e in encrypt_filter (opaque=0xbfffe7a8, control=4, a=0x81114e0, buf=0x8118c28 "", ret_len=0xbfffe6dc) at encode.c:761 #12 0x080bf218 in iobuf_flush (a=0x8110ab8) at iobuf.c:1916 #13 iobuf_flush (a=0x8110ab8) at iobuf.c:1888 #14 0x080bf4d8 in iobuf_push_filter2 (a=0x8110ab8, f=0x8057c00 <compress_filter>, ov=0xbfffe7e4, rel_ov=0) at iobuf.c:1613 #15 0x08058237 in push_compress_filter (out=0x8110ab8, zfx=0xbfffe7e4, algo=2) at compress.c:320 #16 0x080895ec in sign_file (filenames=0x80fdfe0, detached=0, locusr=0x0, encryptflag=1, remusr=0x80fdeb8, outfile=0x0) at sign.c:945 #17 0x08053872 in main (argc=1, argv=0xbfffec3c) at gpg.c:3513 (gdb) quit A debugging session is active. Inferior 1 [process 16027] will be killed. Quit anyway? (y or n) y FWIW : tfoerste@n22 ~ $ zgrep AES /proc/config.gz # CONFIG_SND_MAESTRO3 is not set CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_AES_NI_INTEL=m I simply downgraded to 1.4.6 and gpg works fine again (and kgpg & friends too). Maybe this bug is related to bug #441918 ? I bisected the root cause : https://bugs.g10code.com/gnupg/issue1452 A work around till a fix would be to configure with "--disable-aesni-support" (at least) at my system. https://plus.google.com/107251663111083327808/posts/R661S9gwUMo new laptop, new cpu, new bug found. libgcrypt employs assembler that doesn't work with i7 cpus for AES-NI cipher. workaround: --- libgcrypt-1.5.0-r2.ebuild~ 2012-09-23 18:31:08.000000000 -0400 +++ libgcrypt-1.5.0-r2.ebuild 2012-10-15 14:37:38.817144821 -0400 @@-37,6 +37,7 @@ --disable-dependency-tracking \ --enable-noexecstack \ --disable-O-flag-munging \ + --disable-aesni-support \ $(use_enable static-libs static) } Got bitten by this too. Found the problem keyschedule is not 16 bytes aligned on x86(amd64 appears to get it rigth by pure luck). Came up with this little patch which fixes the problem for me: --- libgcrypt-1.5.0/cipher/rijndael.c.org 2012-11-15 18:00:25.140266907 +0100 +++ libgcrypt-1.5.0/cipher/rijndael.c 2012-11-15 18:04:35.293685269 +0100 @@ -104,7 +104,7 @@ union { PROPERLY_ALIGNED_TYPE dummy; - byte keyschedule[MAXROUNDS+1][4][4]; + byte keyschedule[MAXROUNDS+1][4][4] __attribute__ ((aligned (16))); #ifdef USE_PADLOCK /* The key as passed to the padlock engine. It is only used if the padlock engine is used (USE_PADLOCK, below). */ @@ -114,7 +114,7 @@ union { PROPERLY_ALIGNED_TYPE dummy; - byte keyschedule[MAXROUNDS+1][4][4]; + byte keyschedule[MAXROUNDS+1][4][4] __attribute__ ((aligned (16))); } u2; int rounds; /* Key-length-dependent number of rounds. */ int decryption_prepared; /* The decryption key schedule is available. */ (In reply to comment #6) > Got bitten by this too. Found the problem keyschedule is not > 16 bytes aligned on x86(amd64 appears to get it rigth by pure luck). > Came up with this little patch which fixes the problem for me: /me too - all tests passed fine and no SEGV while using gpg or kgpg hmm, could be enough with 8 byte alignmnet too. I just assumed it should be the same alignment as everything else in this file. Can't test this ATM but feel free :) BTW, could the maintainer add a call to epatch_user in the next rev of this ebuild? Makes it very easy to test new patches by adding them in /etc/portage/patches (In reply to comment #8) 8 byte alignment is sufficient enough here (In reply to comment #9) > BTW, could the maintainer add a call to epatch_user in > the next rev of this ebuild? > Makes it very easy to test new patches by adding them in /etc/portage/patches there's bug #442630 opened for that Did some more investigation and I think may patch may be overkill. Tried this instead: --- libgcrypt-1.5.0/cipher/rijndael.c.org 2012-11-19 17:34:32.569495918 +0100 +++ libgcrypt-1.5.0/cipher/rijndael.c 2012-11-19 17:35:13.481725341 +0100 @@ -1613,7 +1613,7 @@ static const char* selftest_basic_128 (void) { - RIJNDAEL_context ctx; + RIJNDAEL_context ctx ATTR_ALIGNED_16; unsigned char scratch[16]; /* The test vectors are from the AES supplied ones; more or less @@ -1671,7 +1671,7 @@ static const char* selftest_basic_192 (void) { - RIJNDAEL_context ctx; + RIJNDAEL_context ctx ATTR_ALIGNED_16; unsigned char scratch[16]; static unsigned char plaintext_192[16] = @@ -1707,7 +1707,7 @@ static const char* selftest_basic_256 (void) { - RIJNDAEL_context ctx; + RIJNDAEL_context ctx ATTR_ALIGNED_16; unsigned char scratch[16]; static unsigned char plaintext_256[16] = This makes sure the RIJNDAEL_context is 16 bytes aligned for the self tests and this also fixes the problem for me. Where are the Crypto Team? Could we have a new ebuild please? Forgot to mention, I am using stable gentoo gcc: gcc (Gentoo 4.5.4 p1.0, pie-0.4.7) 4.5.4 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. make.conf CFLAGS="-O2 -march=native -g" CHOST="i686-pc-linux-gnu" Interesting read about gcc stack alignment: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 I got the impression one cannot trust gcc to aligne the stack at 16 bytes in many cases. Perhaps this is a better patch? The you won't have to annotate all uses of this structure. --- libgcrypt-1.5.0/cipher/rijndael.c.org 2012-11-19 18:33:32.277273547 +0100 +++ libgcrypt-1.5.0/cipher/rijndael.c 2012-11-19 18:34:10.141484494 +0100 @@ -124,7 +124,7 @@ #ifdef USE_AESNI int use_aesni; /* AES-NI shall be used. */ #endif /*USE_AESNI*/ -} RIJNDAEL_context; +} RIJNDAEL_context ATTR_ALIGNED_16; /* Macros defining alias for the keyschedules. */ #define keyschenc u1.keyschedule (In reply to comment #14) > Perhaps this is a better patch? The you won't have to annotate > all uses of this structure. $> ebuild ... test passes fine with this test (In reply to comment #15) > (In reply to comment #14) > > Perhaps this is a better patch? The you won't have to annotate > > all uses of this structure. > $> ebuild ... test > passes fine with this test Good, then we are two with a working gcrypt :) Any idea how to wake the Crypto Team? Mayby there isn't one anymore? It's on my todo list :( I'll try to patch it in soon, promised. (I need to check if my server has aesni). just FWIW upstream is at least informed : https://bugs.g10code.com/gnupg/issue1452 Yes I've seen the back and forth on the mailing list, I was hoping for a new release but I don't count on it just yet. (In reply to comment #18) > just FWIW upstream is at least informed : > > https://bugs.g10code.com/gnupg/issue1452 Maybe you should mention the latest findings? Not sure if upstream are following this bug. Fixed in libgcrypt-1.5.0-r4. |