Proposal to reduce anti-bundling requirements

[Adam Miller]

On Fri, Sep 11, 2015 at 9:21 AM, Carlos O'Donell <carlos at redhat.com> wrote:
> 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.

+1 - Thanks!

I remember that we spoke but I didn't want to throw you into the
flamewar without warning, but thanks for chiming in! :)

(Also, I got one of those ceramic burr grinders and it's awesome. :) )

>
> 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.

Ah ok, I either misunderstood or mis-remembered. Thank you for the
clarification.

-AdamM

>
> Cheers,
> Carlos.
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct