[110752] in cryptography@c2.net mail archive
RE: More on in-memory zeroisation
daemon@ATHENA.MIT.EDU (Dave Korn)
Fri Dec 14 15:55:48 2007
From: "Dave Korn" <dave.korn@artimi.com>
To: "'Thierry Moreau'" <thierry.moreau@connotech.com>,
"'Leichter, Jerry'" <leichter_jerrold@emc.com>
Cc: "'Peter Gutmann'" <pgut001@cs.auckland.ac.nz>,
<cryptography@metzdowd.com>
Date: Fri, 14 Dec 2007 16:09:17 -0000
In-Reply-To: <4760605A.906@connotech.com>
I've been through the code. As far as I can see, there's nothing in
expand_builtin_memset_args that treats any value differently, so there can't be
anything special about memset(x, 0, y). Also as far as I can tell, gcc doesn't
optimise out calls to memset, not even thoroughly dead ones: for example -
/artimi/software/firmware $ cat memstst.c
#include <string.h>
int foo (void);
int main (int argc, const char **argv)
{
int var[100];
memset (var, 0, sizeof var);
foo ();
return 0;
}
int foo (void)
{
int var[100];
memset (var, 0, sizeof var);
return 0;
}
/artimi/software/firmware $ gcc -O2 memstst.c -o mt
/artimi/software/firmware $ gcc -O2 memstst.c -S -o memstst.s
/artimi/software/firmware $ grep memset memstst.s
call _memset
call _memset
.def _memset; .scl 3; .type 32; .endef
/artimi/software/firmware $
This is not entirely unexpected; memset, even when expanded inline as a
builtin, still has libcall behaviour.
cheers,
DaveK
--
Can't think of a witty .sigline today....
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
