Proposal to reduce anti-bundling requirements

[Carlos O'Donell]

On 09/10/2015 03:42 PM, Adam Miller wrote:
>> It doesn't matter how rare they are, it'll only take a single bundled
>> library handled incorrectly to completely screw a running OS. I don't
>> think this is something that can just be swept under the carpet, it
>> needs to be addressed as a core part of the proposal and currently is
>> not.
>>
> 
> I was talking to someone at Red Hat Summit from the GCC/glibc team and
> I was under the impression they (upstream) are working on something
> that handles the symbol tables to allow parallel installed versions of
> libs. No idea how far this is along but it's something that people are
> working towards.

You spoke to me, and I am responding here to clarify exactly what the
Fedora glibc team trying to do.

The work being done is to enable an alternate linkage model for Ring-0,
where the implementation and interface of ELF-based shared libraries is
split in two. Linking is carried out against a curated Ring-0 SDK
and ensures if we upgrade say, glibc, and have accidentally added a
new symbol, that no new package can use said symbol until the Ring-0 SDK
package is updated to also have that symbol. Updating the Ring-0 SDK
requires careful review and would likely be frozen after GA. The Ring-0
SDK contains headers, stub libraries, and more.

While this idea of an SDK could be extended to all ELF-based shared
libraries in the distribution, it gets much harder outside of Ring-0
and is more work with less benefit. Keep in mind the goal here is to
provide automation and tooling to measure and control the most important
core part of the OS, that layer upon which the other layers rely.

The idea itself could allow you to install a brand new glibc on your
system without impacting any builds you do with rpmbuild, mockbuild,
etc. You are isolated from the implementation by the new linkage
model (using curated sysroots). Thus with the brand new glibc, and
because glibs offers backwards compatibility, you could run newer ISV
applications that require newer glibc, without needing a VM. This
ignores several problems like bug-for-bug compatibility, subtle changes
that alter undefined behaviour or unspecified behaviour, and eventually
result in the failure of an application to run against a new glibc.

However, with the new linkage model it is possible to use it to upgrade,
not not run multiple versions, of shared libraries.

If you need different versions of shared libraries then you need to use
software collections for those libraries (load isolation via the dynamic
loader), containers (load isolation via namespaces), VMs (load isolation
at the kernel level).

If you need different versions of the same shared libraries in the same
process then you must use dlmopen for symbol namespace isolation. Note
that at present dlmopen is not functional for this purpose in upstream
glibc master.

Cheers,
Carlos.