Mike Hearn wrote:
On Thu, 2005-01-06 at 02:28 +0100, pageexec@freemail.hu wrote:
c) Required to implement DCOM universal interface proxies
required as in 'cannot be implemented any other way'?
I'm not sure. These proxies are run-time generated objects. Essentially a DCOM universal/typelib marshaller proxy is a COM interface (so an array of function pointers) that when called marshal the arguments into a packet and dispatch it via the Windows RPC infrastructure. These proxies come in three forms:
- precompiled MIDL/C marshallers
- precompiled MOPs (these are a custom bytecode language fed to a VM
which does the marshalling)
- generated at runtime from type libraries (databases which describe
the types and interfaces used in a program)
I don't know if the second needs runtime code geneation but I don't see any way we can avoid generating code for the third at runtime.
Actually, we shouldn't be generating assembly code on the fly. If you have more than say 16 proxies in a process then it is actually cheaper in terms of memory usage and cache locality to have a set of compiled entry points that can be shared by all proxies. It is even better if you consider the fact that we shouldn't be allocating the memory for the code from the heap, but should be requesting an executable page of memory for each.
Just for the record, PaX and execshield are trying to solve problems that are much better solved by other methods that don't break backwards compatibility. One of the best methods is introducing a terminator canary value between the return address and variables stored on the stack. Obviously, this requires compiler support (which GCC currently lacks, I believe), but it has worked wonders for Microsoft in SP2. It even prevents exploits that PaX/execshield can't, like "return to libc" where the return address is overwritten by the address of another function so that execution jumps into that function.
Rob