Re: [tpm2] dlopen()'ing raw .so files considered bad

* Re: [tpm2] dlopen()'ing raw .so files considered bad
@ 2018-06-02  2:19 Trevor Woerner
  0 siblings, 0 replies; 9+ messages in thread
From: Trevor Woerner @ 2018-06-02  2:19 UTC (permalink / raw)
  To: tpm2

[-- Attachment #1: Type: text/plain, Size: 4410 bytes --]

It seems odd for this project would say "we don't want to have to deal with
versioning". Aren't we now, as we speak, witnessing a
non-backwards-compatible API version break with TSS? How are users supposed
to deal with this? There are existing apps that expect the old TSS and they
will never be updated. Now the TSS is changing in such a way that all those
programs will break if they try to link to and run with the new shared
libraries. If those libraries aren't versioned, how are they, or the
runtime linker supposed to know what to do?

If everyone followed convention, the old apps would look for and
runtime-link against, say, libtss.so.0. Now that the API has changed, the
new library should be called libtss.so.1. New apps can link against this
new library, and everything will work. Distributions are welcome to provide
the old TSS library, or the new one, or both, or neither. Applications that
aren't updated and expect the old API will continue to runtime-link against
libtss.so.0, and new apps or old apps that are updated will runtime-link
against libtss.so.1. No conflicts, no issues.

The "shared library hell" occurs when all versioning is removed and
everyone assumes there's just one, unversioned library against which to
link: libtss.so. How will distros provide support for old and new apps? How
will developers ever know which one is installed?

Versioned libraries are not a new idea. Unversioned shared-object files
will make it difficult for distributions to package these libraries, to the
point where they might decide to not bother trying to package them at all.
Unversioned shared-objects will always be a continual source of instability
for anything that tries to use them. With unversioned shared libraries, the
only way old and new apps can exist on the same system is if these
libraries are installed to different locations and the ELF headers are
manually hard-coded to look in one place and not the other for the correct
library against which to link. What about configuring and compiling apps
that want to use this library? The ./configure step will succeed (because
it would look for libtss.so and find it) but the actual compile-time
linking would fail because, inevitably, symbols won't be found or resolved.
Never mind what will happen at runtime :-)

These conventions (that library.so.N is what should be provided and linked
against and that library.so is just a developer crutch for development time
only) are very old and ingrained in the way all Linux distributions package
libraries.

Unless, of course, you want to take on the task of finding and updating
every single application that ever links to your library every time there
is an API change, for the rest of eternity ;-)

On Fri, Jun 1, 2018 at 12:51 PM, Fuchs, Andreas <
andreas.fuchs(a)sit.fraunhofer.de> wrote:

> P.S. or should we just install everything as .so.0 and merely never
> imagine to have a .so.1 file for
> any tcti ever ?
>
> I'm not that familiar with conventions here.
> ------------------------------
> *From:* Fuchs, Andreas
> *Sent:* Friday, June 01, 2018 18:49
> *To:* Trevor Woerner; Philip Tricca
> *Cc:* tpm2(a)lists.01.org
> *Subject:* RE: [tpm2] dlopen()'ing raw .so files considered bad
>
> I just wanted to make sure we're not doing the same work twice.
>
> The (one) symbol Tss2_Tcti_GetInfo() exported by TCTI-so-files is fixed.
> The data structures
> returned by this (the info itself and the function lookup table) are
> versioned in their first field.
>
> The purpose of this was to not require so-file versioning.
>
> Given this background, would you agree that we should not even start
> introducing versioned
> so-file (e.g. tss2_tcti_socket.so.0) but only ever deploy unversioned
> so-files (tss2_tcti_socket.so).
>
>
> ------------------------------
> *From:* tpm2 [tpm2-bounces(a)lists.01.org] on behalf of Trevor Woerner [
> twoerner(a)gmail.com]
> *Sent:* Friday, June 01, 2018 02:15
> *To:* Philip Tricca
> *Cc:* tpm2(a)lists.01.org
> *Subject:* Re: [tpm2] dlopen()'ing raw .so files considered bad
>
> Thank you. I had been working on this for part of the afternoon and wasn't
> successful, but I wanted to raise the flag sooner rather than later.
>
> I had tried William's patch in isolation, but found more was needed. I was
> going to dive into it harder tomorrow.
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 6260 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread