Skip to content

Conversation

@stefano-garzarella
Copy link
Contributor

@stefano-garzarella stefano-garzarella commented Nov 11, 2024

In cases where this code is utilized only for the libraries in it (e.g. vTPM emulation in Coconut SVSM), we do not need to compile the simulator.

So it would be convenient to have the ability to disable pthread checking, which in that case is not necassary since it is used only by the simulator. Also in Coconut SVSM we don't have pthread support, so it's also a requirement and for now we have our own fork to disable this check.

By default pthread checking remains enabled, so there is no change. --disable-pthread is added to the configure to support this new use case.

In cases where this code is utlized only for the libriers in it
(e.g. vTPM emulation in Coconut SVSM), we do not need to compile
the simulator.

So it would be convenient to have the ability to disable pthread
checking, which in that case is not necassary since it is used only by
the simulator. Also in Coconut SVSM we don't have pthread support, so
it's also a requirement and for now we have our own fork to disable
this check.

By default pthread checking remains enabled, so there is no change.
`--disable-pthread` is added to the configure to support this new use
case.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
@stefano-garzarella
Copy link
Contributor Author

@chrisfenner @bradlitterell @amycnelson any feedback on this?
Is there a chance we can merge it or do I close it?

We have a workaround for now, although not very nice in COCONUT SVSM: https://github.com/coconut-svsm/svsm/blob/5efb4d21b6ce03b7d06dea59b69e814f8f0a13b3/libtcgtpm/Makefile#L170

@chrisfenner
Copy link
Member

@chrisfenner @bradlitterell @amycnelson any feedback on this? Is there a chance we can merge it or do I close it?

We have a workaround for now, although not very nice in COCONUT SVSM: https://github.com/coconut-svsm/svsm/blob/5efb4d21b6ce03b7d06dea59b69e814f8f0a13b3/libtcgtpm/Makefile#L170

Sorry this PR stayed dormant. It seems fine to me, so happy to approve and merge.

However, I want to share a PSA that hopefully will not be terrible news: The build system is likely to change to cmake in the next published version of this code.

@chrisfenner chrisfenner merged commit 7b759a4 into TrustedComputingGroup:main Jun 4, 2025
@stefano-garzarella
Copy link
Contributor Author

@chrisfenner @bradlitterell @amycnelson any feedback on this? Is there a chance we can merge it or do I close it?
We have a workaround for now, although not very nice in COCONUT SVSM: https://github.com/coconut-svsm/svsm/blob/5efb4d21b6ce03b7d06dea59b69e814f8f0a13b3/libtcgtpm/Makefile#L170

Sorry this PR stayed dormant. It seems fine to me, so happy to approve and merge.

Great, thanks!

However, I want to share a PSA that hopefully will not be terrible news: The build system is likely to change to cmake in the next published version of this code.

Thanks for sharing. I think it's not that bad as news :-) We will need to change something, but I think we will find a way to adapt.

@stefano-garzarella
Copy link
Contributor Author

@chrisfenner I guess it was a mistake but this PR was reverted by commit 9bc545f so I just opened a new PR #10 to re-apply this. PTAL.

@chrisfenner
Copy link
Member

Bah, sorry about this Stefano. I must have made a mistake when I checked that these fixes were preserved across the big squash effort that we did for the 184 code last week. I'll take a look this week.

@stefano-garzarella
Copy link
Contributor Author

Bah, sorry about this Stefano. I must have made a mistake when I checked that these fixes were preserved across the big squash effort that we did for the 184 code last week. I'll take a look this week.

@chrisfenner don't worry, let me know if I can help in some way! Thanks!

chrisfenner pushed a commit that referenced this pull request Oct 1, 2025
See #6: this PR was
accidentally merged as a merge commit, which got lost in the recent
refactor+squash for 184. This change cherry-picks the actual commit from
Stefano in that PR.

---

In cases where this code is utlized only for the libriers in it
(e.g. vTPM emulation in Coconut SVSM), we do not need to compile
the simulator.

So it would be convenient to have the ability to disable pthread
checking, which in that case is not necassary since it is used only by
the simulator. Also in Coconut SVSM we don't have pthread support, so
it's also a requirement and for now we have our own fork to disable
this check.

By default pthread checking remains enabled, so there is no change.
`--disable-pthread` is added to the configure to support this new use
case.

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
@chrisfenner
Copy link
Member

Thanks for calling this out, I have re-commited your work in bc29a21. I believe what happened was:

  1. We merged it as a merge commit instead of a squash or rebase.
  2. This (or some other issue) broke the cherry-picking into our internal tree, thus it got reverted by mistake when we rebased, squashed, and pushed to this public repo.

I double checked your other recent PR (#9) and I think despite it also being a merge commit, the work was not accidentally undone.

One more thing: we are full steam ahead on CMake now, so these files are gone in the latest internal tree. For v185 (in public review: https://trustedcomputinggroup.org/specifications-public-review/) I would say to expect the automake files to be gone. If I can be of help to your team in the transition please let me know!

@stefano-garzarella
Copy link
Contributor Author

Thanks for calling this out, I have re-commited your work in bc29a21. I believe what happened was:

1. We merged it as a merge commit instead of a squash or rebase.

2. This (or some other issue) broke the cherry-picking into our internal tree, thus it got reverted by mistake when we rebased, squashed, and pushed to this public repo.

Thanks for the clarification! Much appreciated!

I double checked your other recent PR (#9) and I think despite it also being a merge commit, the work was not accidentally undone.

Yep, I confirm, I did the same yesterday before commenting here, thanks for double-checking!

One more thing: we are full steam ahead on CMake now, so these files are gone in the latest internal tree. For v185 (in public review: https://trustedcomputinggroup.org/specifications-public-review/) I would say to expect the automake files to be gone. If I can be of help to your team in the transition please let me know!

I see, thanks for the update, I'll reach you if we have issue in our project (https://github.com/coconut-svsm/svsm/tree/main/libtcgtpm)

stefano-garzarella added a commit to stefano-garzarella/svsm that referenced this pull request Oct 6, 2025
The next TCG TPM reference implementation release (v185) will remove
the support for autotools [1]. Currently, v184 supports both, so let's
switch to cmake to be prepared.

The main difference is that dependency on TpmBigNum and Math_Ossl was
previously specified in the autotools files when producing libtpm.a and
libplatform.a, but now it is only specified for the final product
(e.g. the simulator in their project). Therefore, we must explicitly
build and link them when producing libtcgtpm.a.

[1] TrustedComputingGroup/TPM#6 (comment)

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
stefano-garzarella added a commit to stefano-garzarella/svsm that referenced this pull request Oct 6, 2025
The next TCG TPM reference implementation release (v185) will remove
the support for autotools [1]. Currently, v184 supports both, so let's
switch to cmake to be prepared.

The main difference is that dependency on TpmBigNum and Math_Ossl was
previously specified in the autotools files when producing libtpm.a and
libplatform.a, but now it is only specified for the final product
(e.g. the simulator in their project). Therefore, we must explicitly
build and link them when producing libtcgtpm.a.

[1] TrustedComputingGroup/TPM#6 (comment)

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
stefano-garzarella added a commit to stefano-garzarella/svsm that referenced this pull request Oct 6, 2025
The next TCG TPM reference implementation release (v185) will remove
the support for autotools [1]. Currently, v184 supports both, so let's
switch to cmake to be prepared.

The main difference is that dependency on TpmBigNum and Math_Ossl was
previously specified in the autotools files when producing libtpm.a and
libplatform.a, but now it is only specified for the final product
(e.g. the simulator in their project). Therefore, we must explicitly
build and link them when producing libtcgtpm.a.

[1] TrustedComputingGroup/TPM#6 (comment)

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
stefano-garzarella added a commit to stefano-garzarella/svsm that referenced this pull request Oct 6, 2025
The next TCG TPM reference implementation release (v185) will remove
the support for autotools [1]. Currently, v184 supports both, so let's
switch to cmake to be prepared.

The main difference is that dependency on TpmBigNum and Math_Ossl was
previously specified in the autotools files when producing libtpm.a and
libplatform.a, but now it is only specified for the final product
(e.g. the simulator in their project). Therefore, we must explicitly
build and link them when producing libtcgtpm.a.

[1] TrustedComputingGroup/TPM#6 (comment)

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
@stefano-garzarella
Copy link
Contributor Author

@chrisfenner I switched to cmake in coconut-svsm/svsm#832, specifically in commit coconut-svsm/svsm@f4fadcc

I tested it, and it works, but I'd really appreciate if you can check it if you have time. Feel free to suggest any improvement!

stefano-garzarella added a commit to stefano-garzarella/svsm that referenced this pull request Oct 16, 2025
The next TCG TPM reference implementation release (v185) will remove
the support for autotools [1]. Currently, v184 supports both, so let's
switch to cmake to be prepared.

The main difference is that dependency on TpmBigNum and Math_Ossl was
previously specified in the autotools files when producing libtpm.a and
libplatform.a, but now it is only specified for the final product
(e.g. the simulator in their project). Therefore, we must explicitly
build and link them when producing libtcgtpm.a.

[1] TrustedComputingGroup/TPM#6 (comment)

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
stefano-garzarella added a commit to stefano-garzarella/svsm that referenced this pull request Oct 16, 2025
The next TCG TPM reference implementation release (v185) will remove
the support for autotools [1]. Currently, v184 supports both, so let's
switch to cmake to be prepared.

The main difference is that dependency on TpmBigNum and Math_Ossl was
previously specified in the autotools files when producing libtpm.a and
libplatform.a, but now it is only specified for the final product
(e.g. the simulator in their project). Therefore, we must explicitly
build and link them when producing libtcgtpm.a.

Update documentation and CI about deps to install to build TPM.
`gcc-c++` is required by the cmake project, otherwise the
"No CMAKE_CXX_COMPILER could be found" error is printed.

[1] TrustedComputingGroup/TPM#6 (comment)

Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants