|
From: Jeffrey W. <nol...@gm...> - 2017-11-28 12:05:34
|
Hi Everyone, We are catching an uninitialized read finding using Valgrind Git Master. The head of the finding is shown below. I suspect it is a valid finding but it kind of strikes me as odd that x86_64 without any -march or -m options is using SSE4. In fact, we build without -march and -m options because that's how distros want it. It feels like I should work on the capabilities problem first rather than chasing the uninitialized read. I can envision a situation where some component assumes a higher ISA is available so it performs an operation on a data structure that should not happen. My question is, where should I begin to look for the root cause? Is this STL or libstdc++? Or maybe glibc? ********** Here's how all files are compiled. $ make valgrind -j 10 g++ -DNDEBUG -g3 -O1 -fPIC -pthread -pipe -DCRYPTOPP_VALGRIND -c cryptlib.cpp g++ -DNDEBUG -g3 -O1 -fPIC -pthread -pipe -DCRYPTOPP_VALGRIND -c cpu.cpp g++ -DNDEBUG -g3 -O1 -fPIC -pthread -pipe -DCRYPTOPP_VALGRIND -c integer.cpp ... ********** Testing SymmetricCipher algorithm Salsa20. ......==2518== Conditional jump or move depends on uninitialised value(s) ==2518== at 0x4C34C26: __memcmp_sse4_1 (vg_replace_strmem.c:1099) ==2518== by 0x48B435: compare (char_traits.h:310) ==2518== by 0x48B435: __gnu_cxx::__enable_if<std::__is_char<char>::__value, bool>::__type std::operator==<char>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (basic_string.h:6006) ==2518== by 0x4F8BAD: operator!=<char, std::char_traits<char>, std::allocator<char> > (basic_string.h:6045) ==2518== by 0x4F8BAD: CryptoPP::Test::TestSymmetricCipher(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >&, CryptoPP::NameValuePairs const&) (datatest.cpp:514) ... ********** And here is the data test that is failing. Its a torture test, and the "r131072" say "create a string that is 128KB of all 0's": Key: 0F62B5085BAE0154A7FA4DA0F34699EC3F92E5388BDE3184D72A7DD02376C91C IV: 288FF65DC42B92F9 Plaintext: r131072 00 CiphertextXorDigest: E00EBCCD70D69152725F9987982178A2 ... (32 byte omitted) Test: EncryptXorDigest |
|
From: Tom H. <to...@co...> - 2017-11-28 13:01:13
|
On 28/11/17 12:05, Jeffrey Walton wrote: > I suspect it is a valid finding but it kind of strikes me as odd that > x86_64 without any -march or -m options is using SSE4. In fact, we > build without -march and -m options because that's how distros want > it. That's fine - glibc has multiple versions of memcmp and other similar routines and selects the best one dynamically at run time based on the capabilities of the CPU that it is running one. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |