|
Message-ID: <20111129210419.GA29622@openwall.com> Date: Wed, 30 Nov 2011 01:04:19 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: .bss size in -jumbo Jim, magnum - On Tue, Nov 29, 2011 at 01:09:23PM -0600, jfoug wrote: > As was found yesterday, when I had MD5 core, we need to memset to 0, the > dyna-allocs of these buffers, to null's. We may only do that if we allocate the buffers for the actual slot count to be used. Otherwise, if we allocate them to the maximum size (like they were in .bss), we'd actually waste memory (whereas with the buffers in .bss we merely wasted address space and maybe a little bit of memory on page table entries). (I haven't yet checked the patches that you prepared so far.) > This keeps the change equal to the > original static buffer in the .bss, which the runtime environ would memset > to zero upon program start. Almost. The important difference is that the read-as-zeroes property for .bss is normally achieved by mapping a shared copy-on-write zero page onto all pages in the range, so memory is not allocated until you actually write to the pages. With a memset(), you force allocation of actual memory. > I am not saying these would core, but if we do > null the string data out, then there should be no latent bug, or worse yet, > a bug that only seems to impact one system (like I found). Yes. Another way to approach this, though, is by introducing a debugging feature into our memory.c where, when the feature is in fact temporarily enabled for debugging, the allocated memory would be initialized to a "bad" value that is likely to cause bugs to manifest themselves. After such debugging and fixing of the bugs (if any), we'd disable the initialization again (till next time we need to check for possible bugs of this nature). Thanks, Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.