|Informative Information for the Uninformed
In order to make use of the generated cookie, functions must be modified to insert it into the stack frame at the time that they are called. This does add some overhead to the call time associated with a function, but its overall effect is linear with respect to a single invocation. The actual modifications that are made to a function's prologue typically involve just three instructions. The cookie that was generated for the image file is XOR'd with the current value of the frame pointer. This value is then placed in the current stack frame at a precisely chosen location by the compiler.
.text:0040214B mov eax, __security_cookie .text:00402150 xor eax, ebp .text:00402152 mov [ebp+2A8h+var_4], eax
It should be noted that Microsoft has taken great care to refine the way a stack frame is laid out in the presence of GS. Locally defined pointers, including function pointers, are placed before statically sized buffers in the stack frame. Additionally, dangerous input parameters passed to the function, such as pointers or structures that contain pointers, will have local copies made that are positioned before statically sized local buffers. The local copies of these parameters are used instead of those originally passed to the function. These two changes go a long way toward helping to prevent other scenarios in which stack-based buffer overflows might be exploited.