Date: Fri, 3 Dec 2010 11:05:53 -0800 From: Geoff Keating <geoffk@...le.com> To: oss-security@...ts.openwall.com Cc: "Chad R. Dougherty" <crd@...t.org>, David Svoboda <svoboda@...t.org> Subject: Re: Interesting behavior with struct initiailization On 03/12/2010, at 6:44 AM, Robert Seacord wrote: > With respect to this specific problem: > >> then the compiler is free to change the padding bytes after 'x.b' to whatever it likes, because you changed 'x.a', even though you might > >> think you cleared them and the compiler would have no reason to make this change. In practice this might manifest in the case of > >> memset (&x, 0, sizeof(x)); >> x.a = 1; x.b = 2; x.c = 3; > >> by the compiler optimising out the 'memset' as a dead store. > > CERT proposed #5 memset_s() to clear memory, without fear of removal (see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1358.pdf). Even if the memset is not removed, a compiler could implement 'x.b = 2' by - setting the low byte of a 32-bit register to 2, leaving the high bytes unchanged - storing all 32 bits of the register into memory which would store nonzero data in the high bytes, possibly containing sensitive information. Content of type "text/html" skipped Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.