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.