Re: Dead stores in src/common/sha2.c

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: "Hamlin, Garick L" <ghamlin(at)isc(dot)upenn(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dead stores in src/common/sha2.c
Date: 2019-05-30 03:57:35
Message-ID: 043403c2-f04d-3a69-aa8a-9bb7b9ce8e5b@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Donald Dong 2019-05-30 04:26:27 Re: undefined symbol: PQgssEncInUse
Previous Message Paul Guo 2019-05-30 03:23:56 Re: undefined symbol: PQgssEncInUse