Per the spec we work on, we can't break it. Good to know, well make this change in the tools: https://github.com/tpm2-software/tpm2-tools/pull/1052

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.

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.

Sorry I guess I was not clear enough. I understand and totally agree with everything you say here. And we want this for all of our "regular" libraries. It's just the tcti at the time was considered its own (special) beast. That's why we only have 1 symbol exported and why the data-type is versioned. The thought was that we want to have interchangable IPC/RPC layer and that tcti-implementations could be provided at any later time independently of the rest of the tss. Similar to OpenSSL engines or PKCS11 .so files. So we can consider tcti libraries to actually never change. Given this, what would you consider the best approach ? Version them anyway is was I understand from this ? ________________________________ From: Trevor Woerner [twoerner(a)gmail.com] Sent: Saturday, June 02, 2018 04:19 To: Fuchs, Andreas Cc: Philip Tricca; tpm2(a)lists.01.org Subject: Re: [tpm2] dlopen()'ing raw .so files considered bad 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@sit.fraunhofer.de<mailto:andreas.fuchs@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@lists.01.org<mailto:tpm2@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@lists.01.org<mailto:tpm2-bounces@lists.01.org>] on behalf of Trevor Woerner [twoerner@gmail.com<mailto:twoerner@gmail.com>] Sent: Friday, June 01, 2018 02:15 To: Philip Tricca Cc: tpm2@lists.01.org<mailto:tpm2@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.