Justin Handville <nanol...@gmail.com> wrote: > Dave Voutila <d...@sisu.io> wrote: > > > Have you considered a libexec approach instead? If the goal is to keep a > > child process having only the executable pages it needs for operations, > > why not split up the program design instead of mucking with ELF stuff? > > That surely has to be even more portable. > > I have. There are other reasons for preferring a single static binary. I > agree that playing with ELF sections is problematic. But, on most > systems I use, this works. It's no worse than assumptions made for GC, > dynamic code generation, or fibers on most platforms. Of course, like > each of these assumptions, it's not guaranteed and, as with what > happened with 7.3, is likely to go away at any time.
A single static binary has no internal random linking, so ROP attack methods are easy. Your binary probably has more syscall stubs than you expect, due to initialzation code and path-not-taken inside higher-level library functions. And you cannot reasonably displace those for hiding. Then if you go dynamic, you have all the stubs at random locations and cannot unmap the real attack surface, but no... you prefer to have fewer but at fixed known offsets. Even then, an attacker is not going to use your unmapped text. They always use ROP on top of lower level primitives. I think your belief in how people attack code is misplaced. I do not think this idea is useful in general, so I don't think we should bend over to support it.
