"Kevin P. Fleming" <kpfleming@xxxxxxxxxx> writes: > We've been playing around with using nested functions recently; they've > got some interesting applications, but now that we've learned more about > how they are generally implemented, we're concerned because it requires > making portions (or all) of the stack executable. > > Is this *always* true? If so, should we be avoiding them completely so > as not to run into systems that disallow executable stack completely and > would not be able to run our code? If the stack is marked executable > (even partially), that seems to run some risk of buffer overflow code > execution anyway... The normal implementation of nested functions requires an executable stack when you take the address of a nested function. If you use nested functions in ways that do not require taking their address (i.e., you simply call the functions), the stack does not need to be executable. On GNU/Linux gcc marks objects which require an executable stack, and the kernel will normally honor that marking when running the program. However, I believe that it is possible to configure GNU/Linux such that the stack is never permitted to be executable. If you expect to distribute your binaries to computers which you do not control, and which may be configured to disallow an executable stack, then you should indeed avoid using nested functions, or at least avoid taking their address. It would be possible to implement taking the address of a nested function differently, such that it does not require an executable stack, by using mmap and mprotect. However, that has not been implemented, and there would be a relatively heavy runtime penalty. Ian
