RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Table of Contents |
---|
people involved
Adam Stolcenburg Pierre Wielders Bart Catrysse Piotr Marcinkowski
Up to now a rdkservice (aka thunderplugin) was typically coded into one single .so file.
...
The Core thunder process is named WPEFramework
process. That process is typically* running in a dedicated container, let's assume for sake of this explanation that name of that container is WPEFRAMEWORK
container. When a thunder plugin is configured as in-process it is running within that WPEFramework
process (and obviously within that same WPEFRAMEWORK
container). Typically for robustness (eg cgroup memory limiting) and security design , several of the rdkservices/thunderplugin do need to run in separate containers. In that case, the thunder plugin is running in a separate process, normally with WPEProcess
in its name and has to be configured to run out-of-process/out-of-container. The plugin code running as part of the WPEFramework
process communicates with the code running as part of the WPEProcess
process using COM RPC.
Up to now a rdkservice (aka thunderplugin) was typically coded into one single .so file. Most of the Thunder plug-in libraries are linked with other libraries because they implement their functionality on the basis of functionality provided by other dynamic libraries. When the Thunder plugin library is loaded, these linked libraries are also loaded, as well as libraries needed by those libraries and so on, until the whole library dependency tree is loaded. And for those plugins that need to run in a different container, it also means that same .so and its defined dependency tree to be loaded by both the thunderplugin process inside its dedicated container (which you would expect) but it is also loaded by core thunder WPEFramework
process inside WPEFRAMEWORK
container. And that core thunder process typically only needs a portion of this library, the part for exposing JSON-RPC part and transforming to COM RPC and much smaller to zero dependency tree but since there is only one single .so for the plugin defined, it has no other choice then to load that same one - with the unnecessary big dependency tree - (linker reads .so and its definition requires access to full dependency in tree) or loading will fail. This also results that that same unnecessary big dependency tree needs to be made available in the WPEFRAMEWORK
container. It exposes the WPEFRAMEWORK
container to bigger attack surface and sometimes goes against the security design and very reasons why container was split off in first place. Here are some other disadvantages that come with with it :
to load individual plugins, the WPEFRAMEWORK
container must mount libraries on which they depend, this causes an excessive number of elements mounted inside this container;
WPEFramework
process context, but the libraries on which the library depends are not unloaded;due to the fact that the process of running an out-of-process plug-in by WPEFramework
consists in first loading the plugin library together with its dependencies on the WPEFramework
side and then spawning the WPEProcess
that loads the same library and its dependencies in a separate container, the memory used to load these libraries mostly increases the amount of memory assigned to the WPEFRAMEWORK
container and not the container in which WPEProcess
is executed;
the memory consumption is unnecessarily increased in the case of dynamic libraries that create Anonymous/Private Dirty areas.
Together with Metrological we agreed on a solution for the above problem which is to split the plugin code loaded on the side of WPEFramework and WPEProcess into two shared libraries.
This only applies to Thunder plugins that are running in the out-of-process mode
...
libWPEFrameworkWebKitBrowser.so
and libWPEFrameworkWebKitBrowserImpl.so
upstreamed by Metrological, see Jira | ||||||
---|---|---|---|---|---|---|
|
Thanks to this we avoid mounting in the WPEFRAMEWORK
the following libraries:
Notes
(*) whether or not the core thunder process runs in dedicated container can depend on operator. For Liberty Global it required to be in separate container for various reasons, one being the security design, core thunder process exposes api's to 3rd party apps via network (ws) and need to restrict attack surface/thread exposure.
...