Re: Dead stores in src/common/sha2.c - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Dead stores in src/common/sha2.c
Date
Msg-id 043403c2-f04d-3a69-aa8a-9bb7b9ce8e5b@iki.fi
Whole thread Raw
In response to Re: Dead stores in src/common/sha2.c  ("Hamlin, Garick L" <ghamlin@isc.upenn.edu>)
Responses Re: Dead stores in src/common/sha2.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 29/05/2019 18:47, Hamlin, Garick L wrote:
> On Wed, May 29, 2019 at 11:01:05AM -0400, Tom Lane wrote:
>> At the same time, I'm not sure if we should just write this off as an
>> ignorable warning.  If the C compiler concludes these are dead stores
>> it'll probably optimize them away, leading to not accomplishing the
>> goal of wiping the values.
> 
> Yeah, I mean it's odd to put code in to zero/hide state knowing it's
> probably optimized out.
> 
> We could also take it out, but maybe it does help somewhere?
> 
> ... or put in a comment that says: This probably gets optimized away, but
> we don't consider it much of a risk.

There's a function called explicit_bzero() in glibc, for this purpose. 
See 
https://www.gnu.org/software/libc/manual/html_node/Erasing-Sensitive-Data.html. 
It's not totally portable, but it's also available in some BSDs, at 
least. That documentation mentions the possibility that it might force 
variables to be stored in memory that would've otherwise been kept only 
in registers, but says that in most situations it's nevertheless better 
to use explicit_bero() than not. So I guess we should use that, if it's 
available.

- Heikki



pgsql-hackers by date:

Previous
From: Paul Guo
Date:
Subject: Re: undefined symbol: PQgssEncInUse
Next
From: Donald Dong
Date:
Subject: Re: undefined symbol: PQgssEncInUse