Menu
▾
▴
valgrind-users
|
From: Dominik S. <dom...@on...> - 2017-08-30 11:51:37
|
Hi,
I have a lot of memcheck errors from libcrypto.
As these seem OK to me (cryprography intentionally works with
uninitialized values) I would like to suppress them.
The errors look like this:
==45293== Conditional jump or move depends on uninitialised value(s)
==45293== at 0x8BEF2F9: BN_bin2bn (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8BF357B: BN_rand (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8BF3159: bn_rand_range (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8BF46A0: BN_BLINDING_create_param (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8C27294: RSA_setup_blinding (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8C1DE46: rsa_get_blinding (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x8C1EE5F: RSA_eay_private_decrypt (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libcrypto.so.1.0.0)
==45293== by 0x91D5FA2: ??? (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x91D3C88: Poco::Crypto::CryptoStreamBuf::close() (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x91D16B1: Poco::Crypto::Cipher::decrypt(std::istream&,
std::ostream&, Poco::Crypto::Cipher::Encoding) (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x91D0EE7:
Poco::Crypto::Cipher::decryptString(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
Poco::Crypto::Cipher::Encoding) (in
/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48)
==45293== by 0x39FE59D: CRYPT::decrypt(CRYPT::RSAKey const&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&) (RSA.C:311)
==45293==
abn the propsed suppression like this:
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:BN_bin2bn
fun:BN_rand
fun:bn_rand_range
fun:BN_BLINDING_create_param
fun:RSA_setup_blinding
fun:rsa_get_blinding
fun:RSA_eay_private_decrypt
obj:/home/cve/distributions/unreleased_distributions/Cheetah_dbg/2017-08-29/onespin360/onespin/lib/Linux_x86_64/libPocoCrypto64.so.48
fun:_ZN4Poco6Crypto15CryptoStreamBuf5closeEv
fun:_ZN4Poco6Crypto6Cipher7decryptERSiRSoNS1_8EncodingE
fun:_ZN4Poco6Crypto6Cipher13decryptStringERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENS1_8EncodingE
fun:_ZN5CRYPT7decryptERKNS_6RSAKeyERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
}
As there are many different BN_* functions causing these errors I would
like to use a global suppression. I tried:
{
crypto2
Memcheck:Cond
obj: */libcrypto.so.1.0.0
}
and
{
crypto2
Memcheck:Cond
...
obj: */libPocoCrypto64.so.*
}
and many variations of these. Only individual ones like
{
bn
Memcheck:Cond
fun:BN_bin2bn
}
do work.
Any hints from your side ?
I am using Valgrind-3.13.0 on CentOS 7 (RHEL 7) with Linux_x86_64.
Many thanks
Dominik
|
|
From: John R. <jr...@bi...> - 2017-08-30 13:11:25
|
> I have a lot of memcheck errors from libcrypto. This is a FAQ! Search the net. libcrypto deliberately uses uninit values as an additional source of randomness. If you want to run memcheck on a program that uses libcrypto, then you should get the source code for libcrypto and build it with a particular #define which turns off those deliberate uninit values. This is well-documented in the source for libcrypto. -- |
|
From: Julian S. <js...@ac...> - 2017-08-30 15:32:55
|
> As these seem OK to me (cryprography intentionally works with > uninitialized values) I would like to suppress them. Another thing you could consider doing, if you really have to use undefined values, is to figure out where they come from (heap or stack allocation, use --track-origins) and then add a VALGRIND_MAKE_DEFINED (or whatever it is called) client request. This lies to Memcheck, claiming the inputs are defined when they are not really. But at least it will not complain about undefinedness from them alone, after that. See <valgrind/memcheck.h>. J |
|
From: Dominik S. <dom...@on...> - 2017-08-30 18:25:08
|
Hi Julian, similar to my answer to John: why isn't suppression working here ? Regards Dominik Am 30.08.2017 um 17:32 schrieb Julian Seward: >> As these seem OK to me (cryprography intentionally works with >> uninitialized values) I would like to suppress them. > Another thing you could consider doing, if you really have to use undefined > values, is to figure out where they come from (heap or stack allocation, > use --track-origins) and then add a VALGRIND_MAKE_DEFINED (or whatever it is > called) client request. This lies to Memcheck, claiming the inputs are > defined when they are not really. But at least it will not complain about > undefinedness from them alone, after that. > > See <valgrind/memcheck.h>. > > J |
|
From: Tom H. <to...@co...> - 2017-08-30 19:08:42
|
Suppression can't really help with this - even if you can stop one or two complaints the undefined bits tend to propagate through the encryption state and hence to everything encrypted or decrypted using the state that is (partially) derived from the undefined data. Tom On 30/08/17 16:51, Dominik Straßer wrote: > Hi Julian, > similar to my answer to John: > why isn't suppression working here ? > > Regards > > Dominik > > Am 30.08.2017 um 17:32 schrieb Julian Seward: >>> As these seem OK to me (cryprography intentionally works with >>> uninitialized values) I would like to suppress them. >> Another thing you could consider doing, if you really have to use undefined >> values, is to figure out where they come from (heap or stack allocation, >> use --track-origins) and then add a VALGRIND_MAKE_DEFINED (or whatever it is >> called) client request. This lies to Memcheck, claiming the inputs are >> defined when they are not really. But at least it will not complain about >> undefinedness from them alone, after that. >> >> See <valgrind/memcheck.h>. >> >> J > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Philippe W. <phi...@sk...> - 2017-08-30 19:13:11
|
On Wed, 2017-08-30 at 11:16 +0200, Dominik Straßer wrote:
> As there are many different BN_* functions causing these errors I would
> like to use a global suppression. I tried:
> {
> crypto2
> Memcheck:Cond
> obj: */libcrypto.so.1.0.0
> }
> and
> {
> crypto2
> Memcheck:Cond
> ...
> obj: */libPocoCrypto64.so.*
> }
> and many variations of these. Only individual ones like
> {
> bn
> Memcheck:Cond
> fun:BN_bin2bn
> }
> do work.
>
> Any hints from your side ?
Try a variant without space after obj:
As far as I can see, the manual for suppression does not describe any
character being special apart of * and ?.
And the suppression parsing code just skips 4 characters when it
recognises obj:
So, space is not special, and the matching logic will try to find
<space>*/libcrypto.so.1.0.0
or similar.
Philippe
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X