MachMessageServer: don’t deal with MACH_SEND_TRAILER.

As documented, MACH_SEND_TRAILER would allow a sender to provide its own
message trailer instead of having the kernel append its own
kernel-generated trailer. This is a Mach feature that supports a network
of multiple Mach hosts, but even in that environment, the option is
restricted to use by privileged callers. In reality, MACH_SEND_TRAILER
has never been implemented in OS X.

The system’s mach_msg_server() family does consider the value of
MACH_SEND_TRAILER, but this is pointless. Any purported trailer set by a
server function would be ignored.

Maintaining this code gives the illusion that it’s functional, so it’s
being removed.

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

Review URL: https://codereview.chromium.org/736493007
This commit is contained in:
Mark Mentovai 2014-11-25 15:00:13 -05:00
parent 85c9318597
commit 306625dac4

View File

@ -117,9 +117,11 @@ mach_msg_return_t MachMessageServer::Run(Interface* interface,
: max_request_size + trailer_alloc;
mach_msg_size_t max_reply_size = interface->MachMessageServerReplySize();
mach_msg_size_t reply_alloc = round_page(
(options & MACH_SEND_TRAILER) ? (max_reply_size + MAX_TRAILER_SIZE)
: max_reply_size);
// mach_msg_server() and mach_msg_server_once() would consider whether
// |options| contains MACH_SEND_TRAILER and include MAX_TRAILER_SIZE in this
// computation if it does, but that option is ineffective on OS X.
mach_msg_size_t reply_alloc = round_page(max_reply_size);
kern_return_t kr;