|
From: Tom H. <to...@co...> - 2010-09-08 14:36:36
|
On 08/09/10 15:26, Seagle, Roger Lee wrote: > Thank you for your help. My understanding of the Mac OS X ASLR feature > is that the mappings are stored in a file: > > /var/db/dyld/dyld_shared_cache_i386.map > /var/db/dyld/dyld_shared_cache_x86_64.map > > for 32 and 64 bit libraries, respectfully. An entry in the file is: > > /System/Library/Frameworks/SyncServices.framework/Versions/A/SyncServices > __TEXT 0x90003000 -> 0x90146000 > __DATA 0xA0000000 -> 0xA000B000 > __OBJC 0xA000B000 -> 0xA0020000 > __LINKEDIT 0x99B02000 -> 0x9B7C7000 > > My interpretation, which could be false, of this file is that the __TEXT > addresses give the location of the shared library when it is loaded into > memory. These randomizations are only updated when patches are applied > via Mac OS X Software Update or by, I think, manually running the > update_dyld_shared_cache command. I have verified that separate runs of > the same program using gdb load libraries and functions in the same > locations (My reliance on gdb here could be a problem.) Yes, linux has something similar called prelinking where a cron job tries to work out an optimal set of placements that means no libraries on the system overlap and then adjusts the default load addresses in the libraries to those addresses. Then means that, normally, programs will tend to load libraries at those addresses and won't have to relocate them on load which makes startup faster. They still can be relocated though, and ld.so will do so if the preferred load address is not available (ie if mmap with MAP_FIXED does not return the desired address) which is what happens under valgrind when the address prelink chose is in the area reserved by valgrind. My guess is that something similar is happening under MAC OS. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |