Announcing security hardened kernels for testing

Robert Shearman rob at
Thu Jan 6 15:47:13 CST 2005

Mike Hearn wrote:

>On Thu, 2005-01-06 at 02:28 +0100, pageexec at 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.


More information about the wine-devel mailing list