is there plan to support 'linker namespace' in glib?

is there plan to support 'linker namespace' in glib?

[zhuao]

Hi experts:


I notice that android bionic support 'linker namespace': https://source.android.com/devices/architecture/vndk/linker-namespace
it provides additional isolation among software components.
it may also benefit some usage: 
 - isolation prebuilt binaries with different toolchain (versioned glibc)
 - it may also give us opportunity to use android binary (HAL) with glibc, by isolating glib and bionic world in different namespace


do you think the above approach is possible?
 if yes, is it possible to add such feature to glibc?


thanks.

Re: is there plan to support 'linker namespace' in glib?

[Szabolcs Nagy]

On 11/03/2019 11:13, zhuao wrote:
> I notice that android bionic support 'linker namespace': https://source.android.com/devices/architecture/vndk/linker-namespace
> it provides additional isolation among software components.
> it may also benefit some usage: 
>  - isolation prebuilt binaries with different toolchain (versioned glibc)
>  - it may also give us opportunity to use android binary (HAL) with glibc, by isolating glib and bionic world in different namespace
> 
> 
> do you think the above approach is possible?
>  if yes, is it possible to add such feature to glibc?

glibc supports dlmopen

but i think such isolation does not work reliably
for the libc itself (or anything that tries to
manage application global state) if you need multiple
instances of that module (e.g. different versions of
the libc or a different libc implementations) in the
same process.

Re: is there plan to support 'linker namespace' in glib?

[Florian Weimer]

* zhuao:

> I notice that android bionic support 'linker namespace': https://source.android.com/devices/architecture/vndk/linker-namespace
> it provides additional isolation among software components.
> it may also benefit some usage: 
>  - isolation prebuilt binaries with different toolchain (versioned glibc)
>  - it may also give us opportunity to use android binary (HAL) with glibc, by isolating glib and bionic world in different namespace
>
>
> do you think the above approach is possible?
>  if yes, is it possible to add such feature to glibc?

There have been many discussions over the year.  The requirements are
quite diverse: some people want group support as in the Solaris linker.
Others want dlmopen with a shared malloc (and perhaps shared other
libraries; our implementation currently shares only the dynamic linker
and nothing else).  Again others want to load the same library multiple
times, disregarding its soname.  Then there is a desire to have some
sort of firewall between different linker namespaces, as a general
framework, so that you can load the same soname multiple times, and
still achieving consistent execution.

I think that anything that is fairly general and actually works is still
a major research effort, in addition to the work that would be needed to
implement it in the current dynamic linker.  While a lot of research has
been done on modules and how to compose them in the 80s, a lot of that
knowledge seems to have been lost or is simply not available to people
working on C/C++ implementations today.

Thanks,
Florian

Re: is there plan to support 'linker namespace' in glib?

[Nicholas Miell]

On 3/11/19 5:50 AM, Florian Weimer wrote:
> * zhuao:
> 
>> I notice that android bionic support 'linker namespace': https://source.android.com/devices/architecture/vndk/linker-namespace
>> it provides additional isolation among software components.
>> it may also benefit some usage: 
>>  - isolation prebuilt binaries with different toolchain (versioned glibc)
>>  - it may also give us opportunity to use android binary (HAL) with glibc, by isolating glib and bionic world in different namespace
>>
>>
>> do you think the above approach is possible?
>>  if yes, is it possible to add such feature to glibc?
> 
> There have been many discussions over the year.  The requirements are
> quite diverse: some people want group support as in the Solaris linker.
> Others want dlmopen with a shared malloc (and perhaps shared other
> libraries; our implementation currently shares only the dynamic linker
> and nothing else).  Again others want to load the same library multiple
> times, disregarding its soname.  Then there is a desire to have some
> sort of firewall between different linker namespaces, as a general
> framework, so that you can load the same soname multiple times, and
> still achieving consistent execution.
> 
> I think that anything that is fairly general and actually works is still
> a major research effort, in addition to the work that would be needed to
> implement it in the current dynamic linker.  While a lot of research has
> been done on modules and how to compose them in the 80s, a lot of that
> knowledge seems to have been lost or is simply not available to people
> working on C/C++ implementations today.
> 
> Thanks,
> Florian
> 

And some people would like direct binding, especially because this is
how Windows and Mac OS already work.

Re:Re: is there plan to support 'linker namespace' in glib?

[zhuao]

thanks you all for the valued information.

could you give me some link for the discussion?
some links for the experimental approach, and links for 'direct binding'.

I know little about linker, and would like to know more background.
thanks


发件人：Nicholas Miell <nmiell@gmail.com>
发送日期：2019-03-12 04:38:57
收件人：Florian Weimer <fweimer@redhat.com>,zhuao <zhuao@ustc.edu>
抄送人：libc-alpha <libc-alpha@sourceware.org>
主题：Re: is there plan to support 'linker namespace' in glib?>On 3/11/19 5:50 AM, Florian Weimer wrote:
>> * zhuao:
>> 
>>> I notice that android bionic support 'linker namespace': https://source.android.com/devices/architecture/vndk/linker-namespace
>>> it provides additional isolation among software components.
>>> it may also benefit some usage: 
>>>  - isolation prebuilt binaries with different toolchain (versioned glibc)
>>>  - it may also give us opportunity to use android binary (HAL) with glibc, by isolating glib and bionic world in different namespace
>>>
>>>
>>> do you think the above approach is possible?
>>>  if yes, is it possible to add such feature to glibc?
>> 
>> There have been many discussions over the year.  The requirements are
>> quite diverse: some people want group support as in the Solaris linker.
>> Others want dlmopen with a shared malloc (and perhaps shared other
>> libraries; our implementation currently shares only the dynamic linker
>> and nothing else).  Again others want to load the same library multiple
>> times, disregarding its soname.  Then there is a desire to have some
>> sort of firewall between different linker namespaces, as a general
>> framework, so that you can load the same soname multiple times, and
>> still achieving consistent execution.
>> 
>> I think that anything that is fairly general and actually works is still
>> a major research effort, in addition to the work that would be needed to
>> implement it in the current dynamic linker.  While a lot of research has
>> been done on modules and how to compose them in the 80s, a lot of that
>> knowledge seems to have been lost or is simply not available to people
>> working on C/C++ implementations today.
>> 
>> Thanks,
>> Florian
>> 
>
>And some people would like direct binding, especially because this is
>how Windows and Mac OS already work.