site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hello, Regards Jean-Daniel -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Jul 21, 2009, at 8:35 AM, Jean-Daniel Dupas <devlists@shadowlab.org> wrote: I'm not sure this is the most appropriate list to ask (and I know the noise/information ratio is pretty high those days ;-) ) but I'm hope the ABI specialists here may help me. Some unix project (with hand-coded asm) require to pass '- read_only_reloc suppress' to the linker to link as dynamic library. I wonder what this mean exactly, and what are the drawback of this flags. I didn't found any information about it, but the ld man page. And I wonder too if there is a better way to solve this issue (what may be change in the asm to avoid linker error). It won't link as a dynamic library without it because you have relocations that apparently live in a read-only text segment. Normally these, if generated by the compiler rather than coded by hand, would be in a read/write segment mapped copy-on-write, which is why the man page for ld claims the compiler will never generate code like this. Without that, you have to suppress so that the page the relocations are in will get remapped by dyld and modified anyway, as needed to use them. This has security implications from two perspectives: (1) since it's in a text page, if the code in the page has a code signature, you're going to make it invalid by dirtying the page, and (2) since type of mapping is only attributable on page boundaries, you're going to open up whatever also happens to be in the pages with the relocs to also being modified, along with the relocs themselves. Depending on your exact use of memory you could also open yourself to stack execution attacks, etc.. Depending on your code signing enforcement settings, the code might decide to simply not work and abort fowwing the mapping change or the page getting dirtied. The easiest way to deal with relocs is to write your code in C/C++/ ObjC instead of hand-coded assembly. If you must deal with it from an assembly perspective, you can use assembler directives to move the relocations into a separate section. The easiest way to know exactly what to do to do that is to write a short chunk of C code that does something similar and thinks it's going to live in a dynamic library so it also has relocs, and then ask the compiler to generate assembly from the C to see what the compiler does in the assembly it generates so you can know what to do in yours. Also realize the contracts between the compiler, assembler, and linker can and do change over time, so your code will be subject to "bit rot" any time those move out from under you. FWIW, unless you are doing unaligned structure assignments or other cases of degerate code, it's pretty rare these days for a human to be able to out-code a compiler in assembly at higher optimization levels, so I was only half-joking about writing the code in C instead. This email sent to site_archiver@lists.apple.com