Page History

...

While this is fine for rdkservices/plugins used in a "in-process" config this has important drawbacks for rdkservices/plugins used in "out-of-process/out-of-container" config when it comes to total memory consumption, accounting and security exposure of container running core thunder process(the WPEFramework process). examples of important rdkservices running out-of-container are OpenCDMi, WebKitBrowser plugins

...

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 For those plugins that need to run in a different container, it also means that same .so and its defined dependency tree to be is 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 :

...

The last step of the splitting process is to set the locator property in the root object of the configuration object in the plugin’s JSON file, to a the name of the library that needs to be loaded by the WPEProcess. Please note that the locator property of the main object of the plugin’s JSON file must still point to the library that is needed by the WPEFramework process. Plugin's JSON file matches the name of the plugin with .json extension and is placed in the /etc/WPEFramework/plugins directory on the rootfs. An exemplary plugin’s JSON file with the modification applied is presented here:

{
  "locator":"libWPEFrameworkWebKitBrowser.so", (…)
  "configuration":{ (…)
    "root":{
      "locator":"libWPEFrameworkWebKitBrowserImpl.so", (…)
    } (…)
  } (…)
}

...

•  .so split of WebkKitBrowser plugin into libWPEFrameworkWebKitBrowser.so and libWPEFrameworkWebKitBrowserImpl.so  upstreamed   proposed by LG and upstreamed by Metrological, see

  Jira
  server JIRA serverId 11deff04-0380-3a3d-a916-0849d4e573f7 key RDKDEV-253

•  .so split of OCDMi plugin, in process of being upstreamed by Liberty Global and reviewed by Comcast, see  https://github.com/rdkcentral/rdkservices/pull/2497  

  • Thanks to this we avoid mounting in the WPEFRAMEWORK the following libraries:

    • libocdm.so.1
      • libgstreamer-1.0.so.0
        • libffi.so.6
        • libgmodule-2.0.so.0
        • libpcre.so.1
        • librdkloggers.so.0
        • liblog4c.so.3
        • libsystemd.so.0
        • libcap.so.2
        • libresolv.so.2
        • liblzma.so.5
        • librt.so.1
      • libgobject-2.0.so.0
      • libglib-2.0.so.0
      • libgstbase-1.0.so.0
      • libnexus.so
      • libbrcmsvpmeta.so
        • libgstaudio-1.0.so.0
        • libgsttag-1.0.so.0
        • libz.so.1
      • libb_os.so

...