search

tpm2-software / tpm2-tools

The source repository for the Trusted Platform Module (TPM2.0) tools
https://tpm2-software.github.io
707 stars 377 forks source link

SAPI support removed? #1327

Closed tomoveu closed 5 years ago

tomoveu commented 5 years ago

Hello,

My team and I are working on a R&D project, which started back in 2017 and throughout 2018 we used the tpm2-tools with SAPI for testing. However, the latest commits on master replace SAPI with ESAPI, which breaks our testing. The commit messages contain no reasoning of this change and we are puzzled what is the technical motivation behind it.

Could you please explain why the SAPI support is being removed and if it is coming back?

Best regards, Dimi

joshuagl commented 5 years ago

The technical motivation is that ESAPI makes some of the functionality we wish to implement much simpler, i.e. HMAC sessions (#956). Are there tools which are broken in your testing? Please let us know which tools and workflows are broken and we will work on fixes for them.

If SAPI support is a requirement you should be able to continue to use the 3.X branch and releases.

williamcroberts commented 5 years ago

Switching from SAPI to ESAPI shouldn't break anything. I'd like to know what broke, specifically, and how to replicate it in a test. From there we can fix it and ensure that we don't regress in the future. Do you have steps for reproducing?

tomoveu commented 5 years ago

Hello William and Josh,

Thank you both for recognizing the importance of this issue!

Replacing SAPI with ESAPI brought changes to the API of most tpm2-tools. I would give "tpm2_hierarchy" as one of the impacted tools. We have break of API at tpm2_hierarchy_create_primary(), which now uses the ESYS context and has an extra argument for "tpm2_session *sess"[1].

Such change is forcing everyone who was using SAPI by now to migrate to ESAPI and ESYS context. Could we instead just have both tpm2-tools variants. Like tools/esapi and tools/sapi, and modify the build process?

Our motivation for such thinking is that ESAPI is essentially using SAPI and both APIs naturally co-exist.

[1] https://github.com/tpm2-software/tpm2-tools/commit/872f457fbd677108ec474377c8e80687531a93c5#diff-45090859350cfaf2b290031722970d9dL108

williamcroberts commented 5 years ago

We have been breaking the API of the command line interface for some time and are making no backwards compatible claims until 4.0 release.

Having those APIs co-exist is not feasible, because we would need to implement all of the session logic, hmac'ing and crypto, that is already included in ESAPI. The reason we switched to ESAPI is to avoid this.

If you need a stable API, I would recommend working off of the 3.X releases, but understand that the bulk of the work is on master heading towards the 4.0 release, and having the command line interface frozen at that point. Ie 4.0 is going to be intentionally different than all previous releases. I understand this is challenging at times, but it will allow us to move into the future more quickly, with a better, more easy to use toolset.

williamcroberts commented 5 years ago

Is their some workflow for you that becomes unsupported or is just the annoyance of updating your scripts?

tomoveu commented 5 years ago

Is their some workflow for you that becomes unsupported or is just the annoyance of updating your scripts?

I do not understand your question about "scripts", all APIs in discussion are written in C.

tomoveu commented 5 years ago

We have been breaking the API of the command line interface for some time and are making no backwards compatible claims until 4.0 release.

Having those APIs co-exist is not feasible, because we would need to implement all of the session logic, hmac'ing and crypto, that is already included in ESAPI. The reason we switched to ESAPI is to avoid this.

If you need a stable API, I would recommend working off of the 3.X releases, but understand that the bulk of the work is on master heading towards the 4.0 release, and having the command line interface frozen at that point. Ie 4.0 is going to be intentionally different than all previous releases. I understand this is challenging at times, but it will allow us to move into the future more quickly, with a better, more easy to use toolset.

Bottom line: The most significant dependency of this project is changed. Design choices and API consequences does not matter until "4.0". The target group for tpm2-tools are end-users, not developers.

Thanks for responding and providing this information!

martinezjavier commented 5 years ago

I do not understand your question about "scripts", all APIs in discussion are written in C.

What @williamcroberts meant is that you are probably using the tpm2-tools from a shell script, and if that's the case then should take into account the non-backward compatible changes from the 3.0 release.

If you were using C code directly, then makes more sense to use the API provided by the tpm2-tss libraries (that way you can choose which layer is more appropriate for your use case).

As others explained, targeting the ESAPI instead of the SAPI has many benefits and since backward compatibility will be break for 4.0 anyways, using ESAPI allows to remove a lot of boiler plate code.

martinezjavier commented 5 years ago

Bottom line: The most significant dependency of this project is changed.

Yes, but the dependency will be also changed for 4.0:

see commit https://github.com/tpm2-software/tpm2-tools/commit/53bc4e6a015646a9fdc17ee066a0e23122ad665f ("docs: update to reference ESAPI, not SAPI").

tomoveu commented 5 years ago

I do not understand your question about "scripts", all APIs in discussion are written in C.

What @williamcroberts meant is that you are probably using the tpm2-tools from a shell script

OK, so this is a wrong assumption and it confirms that tpm2-tools targets end-users, not developers.

If you were using C code directly, then makes more sense to ...

For our TPM2 application we are using SAPI directly. Separately, we have been working to integrate tpm2-tools in our own (let's call it) test framework for the 'TPM2 application'.

Thanks for your input @martinezjavier !

tomoveu commented 5 years ago

Bottom line: The most significant dependency of this project is changed.

Yes, but the dependency will be also changed for 4.0:

see commit 53bc4e6 ("docs: update to reference ESAPI, not SAPI").

Personally, I think we need more complete applications to boost TPM adoption. Therefore, finding out that tpm2-tools is not meant as reusable baseline source code is actually disappointing.

The bottom line for the bigger picture: "tpm2-tools is OSS project not meant to be adopted or integrated, but only to be redistributed as toolset".

Maybe this could be somewhere in the README or Wiki, so other developers would not come asking about broken dependencies and APIs in the future?