From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roman V. Shaposhnick" To: 9fans@cse.psu.edu Message-ID: <20021113014217.A5718@unicorn.math.spbu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [9fans] how to avoid a memset() optimization Date: Wed, 13 Nov 2002 01:42:17 +0300 Topicbox-Message-UUID: 1c35e37e-eacb-11e9-9e20-41e7f4b1d025 There's quite a lively discussion on comp.compilers about memset() use in security related applications and compiler optimization. This idiom of memset'ing secure stuff with 0 is not new, and I've spotted it in Plan9 sources several times -- don't know whether it should be a concern for Plan9 users and developers ( after all, Plan9 has its own C compiler ) but seeing how gcc is making its way, it seems that declaring every buffer volatile ( as John the moderator has suggested ) wouldn't hurt either. Thanks, Roman. From: "Francis Wai" Newsgroups: comp.compilers Subject: how to avoid a memset() optimization Date: 7 Nov 2002 00:51:51 -0500 In a recent article (http://online.securityfocus.com/archive/82/297827), Peter Gutmann raised a concern which has serious implications in secure programming. His example, along the lines of, int main() { char key[16]; strcpy(key, "whatever"); encrpts(key); memset(key, 0, 16); } where memset() was optimized away because memset() is the last expression before the next sequence point and that its side-effect is not needed and that the subject of memset() is an auto variable. The compiler sees that it is legitimate to optimize it away. This is _bad_ news for anyone concerns with sensitive data being left lying around in memory. Various suggestions have been made, such as declaring the variable volatile and having a scrub memory function in a file of its own. I'm wondering if there are better ways such as telling the compiler not to optimize away a function call. [Declaring the array volatile is the right way to do it. The reason volatile exists is to tell the compiler not to do otherwise valid optimizations. -John]