pgsql-server/src backend/nodes/nodes.c backend ...
CVSROOT: /cvsroot
Module name: pgsql-server
Changes by: tgl@postgresql.org 02/12/16 11:22:46
Modified files:
src/backend/nodes: nodes.c
src/backend/utils/mmgr: mcxt.c
src/include : c.h
src/include/nodes: nodes.h
src/include/utils: memutils.h palloc.h
Log message:
Code review for palloc0 patch --- avoid dangerous and unnecessary
practice of evaluating MemSet's arguments multiple times, except for
the special case of newNode(), where we can assume the argument is
a constant sizeof() operator.
Also, add GetMemoryChunkContext() to mcxt.c's API, in preparation for
fixing recent GEQO breakage.
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?
I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the password to zeros after using it. There is a good
chance that the compiler will simply remove the memset from the object code
as it will seem like it can be optimised away...
Just wondering...
Chris
On Tue, 17 Dec 2002, Christopher Kings-Lynne wrote:
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the password to zeros after using it. There is a good
chance that the compiler will simply remove the memset from the object code
as it will seem like it can be optimised away...
Bugtraq discussion claims that GCC >=3 are not affected by this. Variables
which are affected by code that cannot be optimised away should be marked
volitile anyway.
Gavin
Christopher Kings-Lynne wrote:
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the password to zeros after using it. There is a good
chance that the compiler will simply remove the memset from the object code
as it will seem like it can be optimised away...Just wondering...
Chris
Could you post that link? That seems wrong, an explicit memset certainly
changes the operation of the code, and thus should not be optimized away.
Show quoted text
On Tue, 2002-12-17 at 10:49, mlw wrote:
Christopher Kings-Lynne wrote:
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the password to zeros after using it. There is a good
chance that the compiler will simply remove the memset from the object code
as it will seem like it can be optimised away...Just wondering...
Chris
Could you post that link? That seems wrong, an explicit memset certainly
changes the operation of the code, and thus should not be optimized away.
I'd like to see the link too.
I can imagine that it would be possible for it to optimize it away if
there wasn't an additional read/write access which followed. In other
words, why do what is more or less a no-op if it's never accessed again.
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting
On Tue, 2002-12-17 at 11:11, Ken Hirsch wrote:
http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Thanks. Seems I hit the nail on the head. ;)
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting
Ken Hirsch wrote:
http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp
Well, OK, that isn't as bizarre as one could have expected.
Show quoted text
Greg Copeland wrote:
On Tue, 2002-12-17 at 10:49, mlw wrote:
Christopher Kings-Lynne wrote:
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the password to zeros after using it. There is a good
chance that the compiler will simply remove the memset from the object code
as it will seem like it can be optimised away...Just wondering...
Chris
Could you post that link? That seems wrong, an explicit memset certainly
changes the operation of the code, and thus should not be optimized away.I'd like to see the link too.
I can imagine that it would be possible for it to optimize it away if
there wasn't an additional read/write access which followed. In other
words, why do what is more or less a no-op if it's never accessed again.
It has been my experience that the MSC optimizer uses a patented
Heisenberg optimizer. :)