Re: Multiple false-positive warnings from Valgrind - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Multiple false-positive warnings from Valgrind
Date
Msg-id 20170329.142112.251668726.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Multiple false-positive warnings from Valgrind  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
At Wed, 29 Mar 2017 12:34:52 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqQKdxZ-C67OzU+FiHhtU7NOb8qazjrb-9j0u8P0qzCNMA@mail.gmail.com>
> On Thu, Mar 23, 2017 at 5:15 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Tue, Mar 21, 2017 at 10:57 PM, Aleksander Alekseev
> > <a.alekseev@postgrespro.ru> wrote:
> >> Recently I've decided to run PostgreSQL under Valgrind according to wiki
> >> description [1]. Lots of warnings are generated [2] but it is my
> >> understanding that all of them are false-positive. For instance I've
> >> found these two reports particularly interesting:
> >>
> >> ```
> >> ==00:00:40:40.161 7677== Use of uninitialised value of size 8
> >> ==00:00:40:40.161 7677==    at 0xA15FF5: pg_b64_encode (base64.c:68)
> >> ==00:00:40:40.161 7677==    by 0x6FFE85: scram_build_verifier (auth-scram.c:348)
...
> > I can see those warnings as well after calling a code path of
> > scram_build_verifier(), and I have a hard time seeing that as nothing
> > else than a false positive as you do. All those warnings go away if
> > you just initialize just do MemSet(salt, 0, SCRAM_SALT_LEN) before
> > calling pg_backend_random() but this data is filled in with
> > RAND_bytes() afterwards (if built with openssl). The estimated lengths
> > of the encoding are also correct. I don't see immediately what's wrong
> > here, this deserves a second look...
> 
> And it seems to me that this is caused by the routines of OpenSSL.
> When building without --with-openssl, using the fallback
> implementations of SHA256 and RAND_bytes I see no warnings generated
> by scram_build_verifier... I think it makes most sense to discard that
> from the list of open items.

FWIW a document of the function says that,

https://www.openssl.org/docs/man1.0.1/crypto/RAND_bytes.html

> The contents of buf is mixed into the entropy pool before
> retrieving the new pseudo-random bytes unless disabled at compile
> time (see FAQ).

This isn't saying that RAND_bytes does the same thing but
something similar can be happening there.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [POC] A better way to expand hash indexes.
Next
From: Thomas Munro
Date:
Subject: Re: [sqlsmith] Unpinning error in parallel worker