1750497 - Verify if SharedMessageBody::FromMessagesToSharedParent should consistently use fallible allocations

Status: NEW

(Core :: DOM: postMessage, task)

Description

[Jens Stutte [:jstutte]]

The function SharedMessageBody::FromMessagesToSharedParent uses fallible array allocations (and returning false causes an IPC_FAIL here, see also bug 1748852).

The there called helper function SharedMessageBody::FromMessageToSharedParent allocates memory for each item in a non-fallible way, instead.

We should understand, if SharedMessageBody::FromMessagesToSharedParent should really use fallible allocations and in case use them consistent. I assume that the idea behind the IPC_FAIL here is that either the caller asked us to allocate an unreasonable amount of items (and thus can be assumed to have gone nuts) or we would OOM crash anytime soon anyway inside this process, if we are really under memory pressure.

Actually this raises the question, if OOM should be considered a sufficient reason to IPC_FAIL, or better: Shouldn't we have other indicators on the IPC message that tells us if the caller is asking us something unreasonable and can better keep a consistent (crash) behavior on OOM on our side? It might just add noise to our debugging that we potentially crash the calling process here and try to keep alive this process with probably little chances to survive, anyway.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

The way we end up with multiple messages in the array is for cases where a MessagePort is actively being transferred around while the other end of the MessageChannel is sending messages. In this case the messages will be buffered until the transferred port gets entangled in its new global and can receive the buffered messages. If the port has become disentangled again (by being transferred again) when the messages arrive, they will be sent back up to the parent process again.

We would only expect this to happen to the extent we hit allocation failures in one of the following ways:

1. Pathological cases where content code is very buggy and stuck in an infinite loop or content code is fuzzing / trying to do a bad security thing which results in a large number of accumulated messages. It's reasonable / appropriate to return a failure code which will cause the content process to be terminated, probably.
   • Alternately, the buffered messages could be moved around individually rather than in a batch to avoid letting the IPC message size grow a lot.
2. Real memory pressure from real data, as opposed to a silly request from content. That is, if content is creating very large ArrayBuffers and sending them around via PostMessage, there's already been backing memory allocated. It's not like a request for 4 terabytes which can never be fulfilled and fails before being allocated. In this case it seems possible that we might already have crashed from infallible allocations elsewhere (or backing memory failing to be issued when a page gets touched), but it is probably reasonable to try and handle fallible allocations for postMessage in the parent process and cause the content process/tab to be terminated.