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

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Dead stores in src/common/sha2.c
Дата
Msg-id 043403c2-f04d-3a69-aa8a-9bb7b9ce8e5b@iki.fi
обсуждение исходный текст
Ответ на Re: Dead stores in src/common/sha2.c  ("Hamlin, Garick L" <ghamlin@isc.upenn.edu>)
Ответы Re: Dead stores in src/common/sha2.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Paul Guo
Дата:
Сообщение: Re: undefined symbol: PQgssEncInUse
Следующее
От: Donald Dong
Дата:
Сообщение: Re: undefined symbol: PQgssEncInUse