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 (t...@compton.nu) http://compton.nu/ ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
