Hi @leongross, first my apologies for slow SLO on PR review here.

I confess, I don't really understand the purpose of this change. What aspect of go-tpm is pulling in net in your use case? I feel like a build tag that disables some compilation is less ideal than just factoring packages better.

I dug up this "problem" while enabling builds of u-root commands using tinygo.
Tinygo does not (yet) support networking on linux systems, s.t. APIs like net.Dial cannot be used. While building the before mentioned vboot command the build failed and I investigated, that this was due to this go-tpm package requiring the net package.

The function OpenTPM checks the type of the TPM (linux device aka file, or Unix Domain Socket for emulation) at runtime. Hence there is no way to build this package depending on if the type of supported TPM interface (emulation or non-emulation) is known and should be set at build time.

I want to move this decision of the opening mode from runtime to build time.
There could even be something like only file-based, only uds-based, and as is, decide at the runtime, so every use case is covered.

An alternative to build-tags might be several OpenTPM functions so that the dead code elimination could take care of keeping the net package out of the way.

func OpenTPM(path string) (io.ReadWriteCloser, error)       // old API for runtime decision
func OpenTPMFile(path string) (io.ReadWriteCloser, error)
func OpenTPMUds(path string) (io.ReadWriteCloser, error)

EDIT: I tried to split this up as said https://github.com/leongross/go-tpm/tree/ref/emulator-dce but it does not work as expected, tinygo does not pick the dce up and the build fails. It seems as the initially proposed refactoring is the only working solution.

@chrisfenner

any feedback on my proposals? @chrisfenner @rminnich @josephlr

@chrisfenner @rminnich @josephlr any thoughts on that?

Agh, sorry for the delay @leongross. Let me try to find some time to take a look this week. I need to tinker with this to fully understand why the DCE can't help us yet...

First off, sorry for the extensive delays here. We've had trouble with our CI in this repo, and I've been busy with my day-to-day work.

I'm hesitant to add a(nother) build tag here, but I see the problem you're running into.

1. We have this pretty awkward OpenTPM stack, even for the new AP:

   • go-tpm/tpm2/transport/open_other.go

     Line 20 in ec70209

     func OpenTPM(path ...string) (TPMCloser, error) {

   • calls

     go-tpm/legacy/tpm2/open_other.go

     Line 34 in ec70209

     func OpenTPM(path ...string) (tpm io.ReadWriteCloser, err error) {

   • calls

     go-tpm/tpmutil/run_other.go

     Line 29 in ec70209

     func OpenTPM(path string) (io.ReadWriteCloser, error) {

   tpmutil's OpenTPM performs a run-time check of the file mode flags to decide whether to use net.Dial to open the UDS, or just open the file. Thus, the dead code eliminator cannot delete either path.

2. Regardless of whether you are using the legacy or the new API, calling tpmutil directly or not, you're affected. Also this call stack is weird.

3. I don't prefer adding a(nother) build tag here because it really just bandaids the problem you're having.

4. Making any change to transport.OpenTPM will probably break someone.

Here's my suggestion, @leongross please let me know what you think.

Let's add some new transport packages under tpm2/transport, one for each type of TPM someone might want to connect to (Linux device file, Linux UDS, Windows, TCP). This requires the caller to be very explicit about which TPM they want to use, rather than relying on some heuristic under the hood and linking to everything.

Normally I'd suggest that you make this change to unblock yourself, but I'm not willing to make that suggestion after taking 6 weeks to really get to this PR, it's not fair to you. So, I will send a PR and add you as a reviewer.

@chrisfenner thank you for your extensive explanation and the work you are putting in here.
The architectural change you proposed for the transport packages makes a lot of sense looking at its current state. Making the transport type explicit the entire stack down should solve the problem. As soon as you have something worked out, I will review it as quickly as possible.

I sent #369, PTAL @leongross. I'd especially like to know if tinygo happily compiles a program that uses linuxtpm.Open :)

I will have a look at it @chrisfenner.

This PR can be closed since #369 implemented all the necessary changes.