Shared memory internals in Chrome

[Arnold Adam]

Hello,

I would like to know what kind of mechanism is used for shared memory in Chromium and what kind of information is shared between the processes.
Do processes have write access to the shared data or is it read-only? If they can write, how does it work from the security point of view - doesn't sharing the memory between processes create security vulnerabilities, e.g. by corrupting the shared portion of the memory and affecting all processes that read from it?

Also, how can memory sharing work together with process isolation and sandboxing? Those techniques are in place to make sure that the processes shouldn't be able to modify or affect each other in any way, right?

My questions stem from discussion in the ChromeOS group 
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-discuss/aoaXVi5tmQE
Thank you in advance for dispelling my doubts!

[Reilly Grant]

Yes, if the data is corrupted by one process then that could trigger a bug in another process. The difference between shared memory as it is used for inter-process communication and shared memory as it exists between, for example, threads within the same process is that the bounds of the shared memory area are explicitly defined and so the corruption is limited to a particular area that is controlled by process reading the data. Shared memory regions are also not normally mapped to the same address in each process so you can't use pointers as you would normally so it is harder to do the wrong thing. In the case where an index into the shared memory area is needed it can be explicitly checked against the size of the area which is known by the process that mapped it.

Shared memory is used for transferring data between processes that is large enough that copying it through a pipe would be too slow. Unlike the process heap which is a disorganized collection of arbitrary objects a shared memory region usually has a very ridged structure that can be checked by the process reading the data.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/6517b9f0-752b-4e84-b1b8-cff304692709%40chromium.org.

[Primiano Tucci]

On Wed, May 24, 2017, 16:01 Reilly Grant <rei...@chromium.org> wrote:

Yes, if the data is corrupted by one process then that could trigger a bug in another process.

If the "another"  process here is the browser this is a security bug and a violation of our design principles.

The reason why shared memory is not encouraged as a first line solution is precisely this. It is very difficult to get right. 

AFAIK the subsystems that today make user of shared memory (e.g., gpu transfer buffers, discardable) went through security review and are designed assuming that the renderer can be  compromised at any time, and whatever random data is put in the shared memory is not supposed to trigger undefined behavior in the browser.

Likewise, you shouldn't have shared memory between renderers if that could lead to data leaks

AFAIK the general guideline is: don't use shared memory until you can prove you really really need to, and in that case work with security to make sure you have a secure design. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEmk%3DMacAodBpkxzkyzkeapyAu6rZ0uJ801kd_vTXhkC2ztWew%40mail.gmail.com.