Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Dec 2010 11:05:53 -0800
From: Geoff Keating <>
Cc: "Chad R. Dougherty" <>,
 David Svoboda <>
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

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.