Description
We had an offline discussion about these concerns. The activated process should already be protected from suspension long enough to unmarshal these arguments. The activating process could take out a suspension deferral on itself if needed. If neither process involved in the marshaling suspends (or otherwise takes long enough to unmarshal that rundown kicks in), then you shouldn't see premature rundowns.
One other thing you could do is marshal with MSHLFLAGS_TABLESTRONG. This prevents the object from running down at all, which means that if marshal data gets lost in transit (e.g. the client dies before it touches it), and nobody calls CoReleaseMarshalData, then the server will just leak the object. It also allows the same unmarshal data to be unmarshaled arbitrarily many times, which means that you always need to call CoReleaseMarshalData to free the marshal data when you're done with it. Under normal marshaling you can just discard the stream after you call CoUnmarshalInterface, but TABLESTRONG requires the extra cleanup step to avoid leaking.
It's up to you whether you'd prefer to go with explicit suspension avoidance (may lead to premature rundowns if you're wrong and one of the processes does manage to suspend at an inopportune moment) or disabling rundown (may cause permanent leaks in the activating process if the activated process crashes during startup; activating process could potentially do extra work to detect and clean up after this).
In terms of the security policy I mentioned, you do have the option of having your unmarshaling stream object implement IMarshalingStream, and responding to CO_MARSHALING_SOURCE_IS_APP_CONTAINER queries (i.e. checking if the marshaling process is appcontainer). That way we can consider the unmarshaling data less trusted and avoid feeding it to custom unmarshalers that may be exploitable. This security policy and rundown are the most significant things driven off of the marshaling stream.
Overall, it's difficult to wholeheartedly endorse any raw use of CoMarshalInterface with a "dumb" marshaling stream just because it gives us fewer tools to work with to ensure the marshaling is done in a way appropriate to the context. Our preference would be that you marshal this data in a COM call. I'm not going to block the PR over it, since I don't think any of these concerns are fatal, but be warned that you're going off of our most-supported path. There may be dragons.
Originally posted by @brialmsft in #772 (comment)