Investigate the PORT_MESSAGE lengths

_From [timurrrr@google.com](https://code.google.com/u/timurrrr@google.com/) on May 24, 2011 15:07:32_

As can be seen from the issue #407 unaddr report as of r304 (with some additional logging enabled),
RPCRT4.dll!I_RpcSendReceive passes a 256-byte buffer as an OUT PORT_MESSAGE parameter to NtRequestWaitReplyPort.
256 = 0x100 = PORT_MAXIMUM_MESSAGE_LENGTH (on 32-bit systems; on 64-bit systems its value is 512)
// PORT_MESSAGE ends with a variable-length buffer.

As of r304 , our understanding was that the "maximum" size of the buffer passes as a PORT_MESSAGE is
sizeof(PORT_MESSAGE+PORT_MAXIMUM_MESSAGE_LENGTH
but as it turns out it could be less for some syscalls and more for the other.

We need this size during a pre- syscall hook to do the addressability check.
We can't read this size from the syscall argument because it's uninit!
If we underestimate the size we may have a false negative report.
We can also check for addressability again in a post- hook (we know the size at this point)
but the syscall may already write into the redzone at this point.
OTOH, this API is mostly used in the windows guts and there shouldn't be such bugs (hopefully)
If we overestimate the size we may have a false positive report (e.g. issue #407 unaddr)

The LPC stuff is not documented, so we're mostly guessing right now.
(some info: http://www.zezula.net/en/prog/lpc.html )

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=415_