ShmemCreated message serializes shmem size as size_t
Categories
(Core :: IPC, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox67 | --- | fixed |
People
(Reporter: cpearce, Assigned: cpearce)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
When a content process creates a shmem for video frames for a GMP process, it sends the shmem over to the GMP process using an ipc::ShmemCreated message, but that serializes the size of the created shmem as a size_t:
https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/ipc/glue/Shmem.cpp#27
Similar to bug 1525199, when an the content process is aarch64, size_t will serialize to 8 bytes, and if the GMP process is x86, it will try to deserialize the size_t using 4 bytes, and fail.
(It's not clear to me whether this is what happens today with mozilla-central, but it definitely will be the behaviour when bug 1525199 is fixed).
Also, Shmem's have a limit of 32bit for their size anyway:
https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/ipc/glue/Shmem.cpp#127
So we should enforce that the ipc::ShmemCreated message serializes its size using a size-defined type.
Assignee | ||
Comment 1•6 years ago
|
||
Shmem sizes serialized in an ipc::ShmemCreated message should be sent as an
uint32_t rather than a size_t, as size_t is defined as different sizes in 64
and 32 bit builds. If the size isn't consistent, we won't be able to reliably
send this message between cross architecture processes.
Assignee | ||
Comment 2•6 years ago
|
||
Comment 4•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Description
•