Android namespace isolation mechanism

introduction

After Android launched the Treble project from 8.0, it provided a namespace mechanism. Students who understand containers will think that the isolation mechanism of containers is to use Linux's namepsace, but this namespace is not that namespace. Android's namepace is an isolation mechanism for its system to load so, which is a feature of its Linker function. Today, I took the time to summarize Android's namepace related technologies. This technology sharing only involves the namespace function of version 10.0 and before.

concept

Namespace : Every so loaded in Android belongs to a namespace, and the so loaded by the default android_dlopen function belongs to the namespace named "default". In addition to name , each namespace also has a key path attribute. The path attribute determines the path that the namespace can search during the process of loading so.
Link-Namespace : In order to allow one namespace to access the library loaded by another namespace, another namespace can be configured as its link-namespace.
Shared-Libs : After the link-namespace is configured, we can configure which so that the namespace hopes to be shared by the link-namespace.

Loading process

The entire namespace loading mechanism is shown in Figure

1 to query whether the namespace to which you belong can be loaded, and if it has been loaded, the handle will be returned directly;
2 on the contrary, query whether your Link-Namespace has been loaded (Note: the Link-Namespace here is to configure the so Link-Namespace, a member of Shared-Libs), if it has been loaded, the handle will be returned directly;
3 On the contrary, query whether the namespace to which you belong can be loaded, that is, whether it is in the search path specified by it, and if it can be loaded, load it Go to the namespace to which you belong, and then return the handle;
4 On the contrary, query whether your Link-Namespace can be loaded (Note: the Link-Namespace here is the Link-Namespace that specifies that so is Shared-Libs), if it can be loaded, then Load into the Link-Namespace, and then return the handle;
5 Otherwise, it can't be loaded, and an empty handle is returned.

Thinking closed loop

Through the above loading process, it is not difficult to analyze some conclusions (I have also verified by looking at the linker source code and writing test code):
1 If two namespaces x and y, x will share a.so link with y (that is, x Link-Namespace configured as y, a.so is the library they can share and load), and a.so can be accessed in both x and y. If y loads a.so first; later x loads a.so, then a.so cannot be shared. At this time, there will be two a.so mappings in the process, and their code segments, global variables, etc. will not be shared.
2 If two namespaces x and y and z, x will share a.so link with y (that is, x is configured as the Link-Namespace of y, a.so is the library they can share and load), and y will share a.so link Give z (that is, configure y as the Link-Namespace of z, a.so is the library that they can share and load), if a.so is not in the search path of y and z, then even if x can load a.so, z cannot Load to a.so. That is, link sharing cannot be delivered .