Add a ReceiveLarge parameter to MachMessageServer::Run()

Add a ReceiveLarge parameter to MachMessageServer::Run().

Previously, MachMessageServer::Run() only provided two strategies for
dealing with large messages, indicated by mach_msg() returning
MACH_RCV_TOO_LARGE: the receive buffer could be reallocated and the
message received, or the entire function could return MACH_RCV_TOO_LARGE
to the caller. There are situations where an intermediate behavior might
be desirable. This intermediate behavior would allow the function to
continue waiting for another message without returning an error to the
caller or attempting to receive the large message. This is desirable
when dealing with fixed-sized messages and a receiver that might be sent
messages by unknown, possibly-malicious callers. This can happen when
the corresponding send right is published with the bootstrap server, for
example.

Existing users continue to request their existing behavior, typically
receiving an error when encountering a large message.
catch_exception_tool will use the new “ignore” behavior when running in
persistent mode.

TEST=util_test MachMessageServer.*
R=rsesek@chromium.org

Committed: https://chromium.googlesource.com/crashpad/crashpad/+/79b4434c81370b66819f8a2e2b47f947bfdac2cc

[Mark Mentovai, 2014-11-24 23:01:27]

mark@chromium.org changed reviewers:
+ rsesek@chromium.org

[Mark Mentovai, 2014-11-24 23:01:27]

I’ve been concerned about this quirk of MachMessageServer for a little while.

In https://codereview.chromium.org/756603003/, ChildPortHandshake::RunServer()
runs a MachMessageServer loop. It doesn’t want a large message sent by any rando
to derail the entire loop, so it special-cases MACH_RCV_TOO_LARGE. This is a
concern because it publishes a send right with the bootstrap server, where
anyone else can grab a copy. If unhandled, malicious code would be able to force
the handshake to fail.

The retry-on-large-message behavior seems desirable for other situations, and
I’m planning on using it elsewhere, so it seemed better to work it into
MachMessageServer directly rather than having multiple sites deal with the
problem themselves. Another place I’m planning on using this is in the handler’s
exception-receiving loop: a compromised renderer might send a large message to
its exception port, and this shouldn’t cause the handler to fail or otherwise
end unable to serve other clients. There’s absolutely no reason to attempt to
receive these large messages to be able to respond to broken clients. With the
launchd design, a failure would be undesirable but tolerable, because launchd
would have restarted the handler. Since we’re now looking at eschewing launchd,
we need this exception-receiving loop to be resilient against these cases on its
own.

[Robert Sesek, 2014-11-25 19:29:34]

LGTM

[Mark Mentovai, 2014-11-25 19:48:48]

Committed patchset #1 (id:1) manually as
79b4434c81370b66819f8a2e2b47f947bfdac2cc (presubmit successful).