Don't write beyond the value of `TPMPTNVBufferMax`

[Foxboron]

It seems like some platforms don't support a large buffer for writing? This results in RC_SIZE errors that ssh-tpm-agent seems to choke on.

Foxboron/ssh-tpm-agent#102

It seems like we could read out TPMPTNVBufferMax and split the writes..? But it's a bit unclear to me how to figure this out as I can't reproduce this locally.

[salrashid123]

i think go-tpm would need to recall the capabilites and split it up with offsets on nvwrite. given that go-tpm is really low level, maybe something like this needs to be done at a higher level.

this example here defines a large nv (to the limit for swtpm), and then write to that using in chunks.

https://gist.github.com/salrashid123/14ffb2bb2751301f53f9924f1fb26382

(other ref)

[chrisfenner]

If I understand the concern correctly, we're sending a TPM a buffer that is too big during TPM2_NV_Write (and would have the same problem reading that amount of data with TPM2_NV_Read.

I agree that reading TPM_PT_NV_BUFFER_MAX and chunking the writes is the answer. Without a local repro, you might have to rig up simulator-based fake that specifically filters NV_Write and NV_Read requests of "pretend-too-large" size.

[Foxboron]

@chrisfenner Honestly, It's unclear to me what the problem actually is. It seems to be a buffer thing but ssh-tpm-agent doesn't interact with NV_Write/NV_Read so is there other commands that can have buffer size issues?

[chrisfenner]

Oh. That's weird.

Other properties to query:

• TPM_PT_INPUT_BUFFER
• TPM_PT_MAX_COMMAND_SIZE
• TPM_PT_MAX_DIGEST

Of course, if you can instrument the tool enough to say exactly what command is failing, that will help

[Foxboron]

I'll try a custom build of ssh-tpm-agent and go-tpm with logging around those values and see if the reporter can run it and reproduce. Thanks!