Re: Multiple false-positive warnings from Valgrind
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Multiple false-positive warnings from Valgrind |
Дата | |
Msg-id | 20170329.142112.251668726.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Multiple false-positive warnings from Valgrind (Michael Paquier <michael.paquier@gmail.com>) |
Список | 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 по дате отправления: