From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] how to avoid a memset() optimization MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-nlauuabcipfsbngauhqbwasmcy" Date: Tue, 12 Nov 2002 19:20:30 -0500 Topicbox-Message-UUID: 1c3abb6a-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-nlauuabcipfsbngauhqbwasmcy Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit We don't optimize out subroutine calls that are in live codd, mostly because they might have side effects. We do optimize out expressions that don't get called. --upas-nlauuabcipfsbngauhqbwasmcy Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Nov 12 17:43:16 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Tue Nov 12 17:43:15 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 5676B19A6C; Tue, 12 Nov 2002 17:43:09 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 81BF019A6A for <9fans@cse.psu.edu>; Tue, 12 Nov 2002 17:42:18 -0500 (EST) Received: (from vugluskr@localhost) by unicorn.math.spbu.ru (8.9.3/8.9.3) id BAA05742 for 9fans@cse.psu.edu; Wed, 13 Nov 2002 01:42:17 +0300 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 X-Mailer: Mutt 1.0pre3i Subject: [9fans] how to avoid a memset() optimization Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 13 Nov 2002 01:42:17 +0300 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] --upas-nlauuabcipfsbngauhqbwasmcy--