Re: openssl valgrind failures on skink are due to openssl issue
От | Andres Freund |
---|---|
Тема | Re: openssl valgrind failures on skink are due to openssl issue |
Дата | |
Msg-id | 20190618230843.zv6hcpuxii2ced7s@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: openssl valgrind failures on skink are due to openssl issue (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: openssl valgrind failures on skink are due to openssl issue
|
Список | pgsql-hackers |
Hi, On 2019-06-11 14:07:29 -0700, Andres Freund wrote: > On 2019-06-11 16:55:28 -0400, Tom Lane wrote: > > Andres Freund <andres@anarazel.de> writes: > > > I can't think of a better way to fix skink for now than just disabling > > > openssl for skink, until 1.1.1d is released. > > > > Couldn't you install a local valgrind exclusion matching this stack trace? > > Unfortunately no. The error spreads through significant parts of openssl > *and* postgres, because it taints the returned random value, which then > is used in a number of places. We could try to block all of those, but > that seems fairly painful. And one, to my knowledge, cannot do valgrind > suppressions based on the source of uninitialized memory. What we could do is add a suppression like: { broken-openssl-accesses-random Memcheck:Cond ... fun:pg_strong_random fun:InitProcessGlobals fun:PostmasterMain fun:main } (alternatively one suppression for each RAND_status, RAND_poll, RAND_bytes(), to avoid suppressing all of pg_strong_random itself) and then prevent spread of the uninitialized memory by adding a VALGRIND_MAKE_MEM_DEFINED(buf, len); after a successful RAND_bytes() call. I tested that that quiesces the problem locally. Probably not worth pushing something like that though? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: