valgrind-users

[Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Jeffrey W. <nol...@gm...>]

I'm having trouble writing a suppression rule.

Here's the finding:

==6516== Use of uninitialised value of size 8
==6516==    at 0x533B449: _x86_64_AES_encrypt_compact (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x533B6DA: fips_aes_encrypt (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x56FBC47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x56FBD27: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x56FBE47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0xFFEFFFE17: ???
==6516==  Uninitialised value was created by a heap allocation
==6516==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==6516==    by 0x53575AF: CRYPTO_malloc (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x53FB52B: drbg_get_entropy (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x534C312: fips_get_entropy (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x534CABE: FIPS_drbg_instantiate (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x53FB94E: RAND_init_fips (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x5403F5D: EVP_add_cipher (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x507B7C0: SSL_library_init (in
/usr/local/ssl/lib/libssl.so.1.0.0)
==6516==    by 0x4103E7: DoStartupOpenSSL() (ac-openssl-1.cpp:494)
==6516==    by 0x419504: main (main.cpp:69)
==6516==

Here are the rules I'm trying to use to suppress the finding:

{
   RAND_init_fips_1
   Memcheck:Cond
   ...
   fun:RAND_init_fips
   ...
}

{
   RAND_init_fips_2
   Memcheck:Value8
   ...
   fun:RAND_init_fips
   ...
}

{
   RAND_init_fips_3
   Memcheck:Value4
   ...
   fun:RAND_init_fips
   ...
}

I believe I'm using the frame-level wildcard according to the manual
(under Section 2.5, http://valgrind.org/docs/manual/manual-core.html):

    A location line may also be simply "..." (three dots). This is a
    frame-level wildcard, which matches zero or more frames.
    Frame level wildcards are useful because they make it easy
    to ignore varying numbers of uninteresting frames in between
    frames of interest. That is often important when writing
    suppressions which are intended to be robust against
    variations in the amount of function inlining done by compilers.

Any ideas what I'm doing wrong?

Thanks in advance.

**********

My version of Valgrind (built from sources):

$ which valgrind
/usr/local/bin/valgrind
$ valgrind --version
valgrind-3.9.0

And the OS (Debian 7.3, x64, fully patched):

$ uname -a
Linux debian-q500 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Tom H. <to...@co...>]

On 05/02/14 22:21, Jeffrey Walton wrote:

> ==6516== Use of uninitialised value of size 8
> ==6516==    at 0x533B449: _x86_64_AES_encrypt_compact (in
> /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x533B6DA: fips_aes_encrypt (in
> /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x56FBC47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x56FBD27: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x56FBE47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0xFFEFFFE17: ???

So this is the stack you are matching against.

> {
>     RAND_init_fips_1
>     Memcheck:Cond
>     ...
>     fun:RAND_init_fips
>     ...
> }

and this is one of the match rules, which uses a function that is not in 
the stack being matched.

> Any ideas what I'm doing wrong?

Yes, you're trying to match against the location where the memory is 
allocated, but suppression rules (except for leak suppressions) match 
against the stack at the point the error is detected.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Jeffrey W. <nol...@gm...>]

Thanks Tom. So apparently I'm doing something wrong.

On Wed, Feb 5, 2014 at 5:40 PM, Tom Hughes <to...@co...> wrote:
> On 05/02/14 22:21, Jeffrey Walton wrote:
>
>> ==6516== Use of uninitialised value of size 8
>> ==6516==    at 0x533B449: _x86_64_AES_encrypt_compact (in
>> /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x533B6DA: fips_aes_encrypt (in
>> /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x56FBC47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x56FBD27: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x56FBE47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0xFFEFFFE17: ???
>
>
> So this is the stack you are matching against.
That's part of the finding, but not the whole finding.

>> {
>>     RAND_init_fips_1
>>     Memcheck:Cond
>>     ...
>>     fun:RAND_init_fips
>>     ...
>> }
>
>
> and this is one of the match rules, which uses a function that is not in the
> stack being matched.
>
>
>> Any ideas what I'm doing wrong?
>
>
> Yes, you're trying to match against the location where the memory is
> allocated, but suppression rules (except for leak suppressions) match
> against the stack at the point the error is detected.

It appears to me that the finding ends with:

==6566== Use of uninitialised value of size 8
==6566==    at 0x533B449: _x86_64_AES_encrypt_compact (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)

And starts with:

==6566==    by 0x4103E7: DoStartupOpenSSL() (ac-openssl-1.cpp:494)
==6566==    by 0x419504: main (main.cpp:69)

(Sorry to do it in reverse order. It seems natural because it follows
Valgrind's onscreen output).

Are you stating those are two different findings? If they are two
different findings, shouldn't there be two different:

==6566==    by 0x4103E7: DoStartupOpenSSL() (ac-openssl-1.cpp:494)
==6566==    by 0x419504: main (main.cpp:69)

Jeff

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Tom H. <to...@co...>]

On 05/02/14 22:49, Jeffrey Walton wrote:

> Are you stating those are two different findings? If they are two
> different findings, shouldn't there be two different:

Well it's one finding, but there are two pieces of information 
associated with that finding.

The first is the location where the uninitialised data was used and the 
second (which occurred at some earlier point during the program's 
execution) is the location where the memory containing the uninitialised 
data was allocated.

The two are separated by the "Uninitialised value was created by..." 
line which tells you that what follows is the location of the allocation.

Because suppressions match at the point where the data is accessed they 
match against the stack at that point in time.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Jeffrey W. <nol...@gm...>]

On Wed, Feb 5, 2014 at 5:54 PM, Tom Hughes <to...@co...> wrote:
> On 05/02/14 22:49, Jeffrey Walton wrote:
>
>> Are you stating those are two different findings? If they are two
>> different findings, shouldn't there be two different:
>
>
> Well it's one finding, but there are two pieces of information associated
> with that finding.
>
> The first is the location where the uninitialised data was used and the
> second (which occurred at some earlier point during the program's execution)
> is the location where the memory containing the uninitialised data was
> allocated.
>
> The two are separated by the "Uninitialised value was created by..." line
> which tells you that what follows is the location of the allocation.
>
> Because suppressions match at the point where the data is accessed they
> match against the stack at that point in time.
Thanks Tom.

Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.

A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.

A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.

I'm fairly certain I need to include RAND_init_fips to rule out a
legitimate uninitialized read, but I'm not sure how to do it.

Any ideas how to craft this rule?

Thanks in advance.

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Tom H. <to...@co...>]

On 05/02/14 23:00, Jeffrey Walton wrote:

> Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.
>
> A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.
>
> A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.
>
> I'm fairly certain I need to include RAND_init_fips to rule out a
> legitimate uninitialized read, but I'm not sure how to do it.
>
> Any ideas how to craft this rule?

You can't. There is no way to write a suppression which says "don't 
worry about reads from the memory that was allocated at location X" 
which is what you are tryng to do.

Your problem presumably is that something is deliberately mixing 
uninitialised memory into the random pool - whether that is a sensible 
idea is a good question but lets not repeat the whole Debian openssl 
debate again...

The best fix is to have whatever is doing that use a client request to 
deliberately mark the data in the random as initialised because in a 
logical sense it is even though strictly speaking it isn't.

Otherwise you're stuck trying to suppress everything that winds up 
depending on data from the random pool.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Jeffrey W. <nol...@gm...>]

On Wed, Feb 5, 2014 at 6:06 PM, Tom Hughes <to...@co...> wrote:
> On 05/02/14 23:00, Jeffrey Walton wrote:
>
>> Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.
>>
>> A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.
>>
>> A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.
>>
>> I'm fairly certain I need to include RAND_init_fips to rule out a
>> legitimate uninitialized read, but I'm not sure how to do it.
>>
>> Any ideas how to craft this rule?
>
>
> You can't. There is no way to write a suppression which says "don't worry
> about reads from the memory that was allocated at location X" which is what
> you are tryng to do.
Thanks Tom. That's not the answer I wanted :)

Jeff

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

[Philippe W. <phi...@sk...>]

On Wed, 2014-02-05 at 18:17 -0500, Jeffrey Walton wrote:
> On Wed, Feb 5, 2014 at 6:06 PM, Tom Hughes <to...@co...> wrote:
> > On 05/02/14 23:00, Jeffrey Walton wrote:
> >
> >> Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.
> >>
> >> A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.
> >>
> >> A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.
> >>
> >> I'm fairly certain I need to include RAND_init_fips to rule out a
> >> legitimate uninitialized read, but I'm not sure how to do it.
> >>
> >> Any ideas how to craft this rule?
> >
> >
> > You can't. There is no way to write a suppression which says "don't worry
> > about reads from the memory that was allocated at location X" which is what
> > you are tryng to do.
> Thanks Tom. That's not the answer I wanted :)
> 
> Jeff
Note that I believe we already had multiple requests to have
suppression entries which could match the "two" stacktraces of a
reported error, e.g. for the case you present,
but also for the helgrind errors, which also typically have
more two stacktraces.

So, you might enter an entry in bugzilla (with severy wish :)
and hope someone is interested to work on that.

Philippe