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
|
Список | 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 по дате отправления: