> And this is not just for libffi that we can somehow do this within libffi. > I would like to provide something so that the maintainers of other > dynamic code can use it to convert their dynamic code to static code > when their dynamic code is a lot more complex that the libffi trampoline. Having worked on stuff "like" this -- removing "arbitrary" codegen from a system and replacing with "templatized" codegen, because the runtime banned runtime codegen, and despite being a lover of shared source and shared libraries, I'm afraid to say, this is not an area very amenable to sharing. Specifically I've done this twice. Providing examples is good and people will copy/paste. The problem can be sort of split up into parts: - The management of a pool of thunks. - The thunks. Where I mostly give up is: - Generalizing the thunks, such as to share them. the management of the pool is kinda sorta generalizable, but the thunks, again, it is difficult/impossible to share. I do think, there is *some* opportunity here. Stuff like, for some function f(x,y), produce a new function f2(y,x) that swaps params and calls f or a new function f3(x), that sets y to a constant and calls f. Like my favorite Scheme-ish: Given a static binary function: function add(x, y) (+ x y) Provide for dynamically creating specialized unary functions: function make-add(x): return function addx(y) (+ x y) And then generalized to arbitrary rearrangement and hardcoding of parameters. I believe this is libffi, and might be able to replace some people's codegens. It sounds a bit contrived, but I know this actually resembles real world cases. Consider some library that accepts function pointers but fails to accept an additional void* to pass on to them. qsort/bsearch are the classic broken-ish cases. Wrapping Windows WNDPROCs in C++ are another -- you want a "thunk" to take the Win32-defined parameters, and add a this pointer as well. So you create a new function and when you create the function you give it the this pointer to hardcode within it. i.e. atlthunk. > The kernel based solution gives you the opportunity to make additional > security checks at the time a trampoline is invoked. A purely user level > solution cannot do that. E.g., I would like to prevent even the minimal > trampoline from being used in BOP/ROP chains. Like what? At some point, it is just normal static code. Once libffi is fixed, so that the iOS solution is available on all platforms, it is all just normal code. There are no checks to apply differently to libffi and its output than any other code, right? > Before I implement the user land solution recommended by reviewers, I just want > an opinion on where the code should reside. > > I am thinking glibc. The other choice would be a separate library, say, libtramp. > What do you recommend? What functionality does the user land solution provide? I suggest, other than lobbying the libffi developers to do their part, and perhaps giving in and doing it yourself, identity some other dynamic but non-arbitrary code generations that you wish to fix and work through fixing it. See what patterns emerge. - Jay
