Re: openssl valgrind failures on skink are due to openssl issue - Mailing list pgsql-hackers

From Andres Freund
Subject Re: openssl valgrind failures on skink are due to openssl issue
Date
Msg-id 20190618230843.zv6hcpuxii2ced7s@alap3.anarazel.de
Whole thread Raw
In response to Re: openssl valgrind failures on skink are due to openssl issue  (Andres Freund <andres@anarazel.de>)
Responses Re: openssl valgrind failures on skink are due to openssl issue
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: PG 12 beta 1 segfault during analyze
Next
From: Justin Pryzby
Date:
Subject: ANALYZE: ERROR: tuple already updated by self