libcrypto++/libcryptopp and Shared Objects

[Jeffrey Walton]

Packages: libcrypto++8 and libcrypto++8-dev

Crypto++ received a few GNU Linux bug reports [1, 2], and Wei Dai vetted out the crash due to global object destruction in a shared object (the bug is not present in a static library). The crash fix was sufficient to support shared objects, and the commit occurred at revision 496 [3].

Please ensure the distribution is using revision 496 or higher of Crypto++. Crypto++ version 5.6.1 includes revision 496, while Crypto 5.6.0 does not include the revision.

While trying to duplicate the issues, a stress test was written. It might be a good test case for the distribution's build bot. The program generates 96 threads which perform dynamic loads/unloads (with lots of overlap) to ensure proper cleanup on library unload. The stress test, released under GPLv3, is available at http://www.cryptopp.com/wiki/Linux#Note_for_Distribution_Packagers.

The latest Crypto++ library can be downloaded directly from the website at http://www.cryptopp.com. The 5.6.1 ZIP includes shared object support (the ZIP will get stale over time since the archive is frozen). Crypto++ can also be fetched from SourceForge, which is always up to date. Issue "svn checkout https://cryptopp.svn.sourceforge.net/svnroot/cryptopp/trunk/c5 cryptopp"/

In addition to revision 496, the commit at 492 included a SHA-2 bug fix on x64 with GCC optimizations enabled [4].

Finally, this was also reported to Debian in issue 599639. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599639.

Jeffrey Walton,
Friend of the Crypto++ Library,

[1] Errors with multiple loading cryptopp as shared lib on Linux,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48

[2] RTLD_GLOBAL and libcryptopp.so crash,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/7eae009a4e02e726

[3] http://cryptopp.svn.sourceforge.net/viewvc/cryptopp?view=revision&revision=496

[4] http://cryptopp.svn.sourceforge.net/viewvc/cryptopp?view=revision&revision=492

[Jeffrey Walton (noloader)]

Hi All,

From [1], it appears that the original bug report stemmed from violating ODR in the shared object which called Crypto++, and *not* an ODR violation in Crypto++.

Take away: (1) Crypto++ 5.6.1 is most likely not responsible for a crash; and (2) 5.6.1 is useful to fix (work around) a GCC/x64 code generation bug in SHA-2.

Please close this report at the earliest convenience.

JW

[1] Errors with multiple loading cryptopp as shared lib on Linux,
http://groups.google.com/group/cryptopp-users/browse_thread/thread/68fbc22e8c6e2f48