TODO list for v0.11

[stefanberger]

For v0.11:

• Enable support for PCAP packet capture: Implement support for capturing TPM packet exchanges to pcap files #1075
  • pcap file written on big endian machine cannot be read by wireshark on Windows; works fine of Linux
• Enable CAs with ML-DSA support to sign EK and platform certs with ML-DSA (?)
  • libtpms: Enlarge max. NVRAM area size from 2kb to 10(?)kb to be able to store the much larger certificates in one NVRAM area? Or spread it over multiple NVRAM areas?
  • Merge: WIP: swtpm_cert: Enable CAs with ML-DSA key to sign a certifcate #1064
• Test cases for ML-DSA and ML-KEM in default-v2 profile
• Examine how to deal with the need for bigger buffers.

  • How does libtpms deal with buffer sizes? If a response from TPM is bigger than the old 4kb, what happens?

    • There's TPM_BUFFER_MAX (4kb) that serve's as an upper limit for the response buffer size. This needs to change in libtpms v0.11.
    • The RuntimeProfile could provide info about the size of the buffer that is needed for the active profile. -> ML-KEM and ML-DSA key types should have info providing needed buffer size
    • Otherwise introduce TPM2_BUFFER_MAX (8kb) and use it.

  • How does swtpm deal with buffer sizes? If a response from TPM is bigger than the old 4kb, what happens? Same for command sent from QEMU.

    • If a TPM command (from QEMU) is bigger than 4kb, then the receive function will leave the rest of the bytes in the socket, leading to trouble when the next command is read (possible issue for swtpm v0.10 with libtpms v0.11 and using ML-DSA)
      • Need to backport patch to swtpm v0.10 so that it queries libtpms for TPM2_BUFFER_MAX and allocates a bigger buffer.
    • If libtpms was restricted to creating 4kb responses (via libtpms TPM_BUFFER_MAX or TPMLIB_SetBufferSize), it would probably cause it to create an error response.

  • How does QEMU deal with buffer sizes? If a response from TPM is bigger than the old 4kb, what happens?

    • It is important that tpm_emulator_get_buffer_size() (CMD_SET_BUFFERSIZE used for querying) returns the needed buffer size so that unexpected large packets are never received from the TPM but there's always enough buffer available. CMD_SET_BUFFERSIZE was sent before CMD_INIT -- check whether this could return a profile's required buffersize if used in this order; see QEMU's tpm_emulator_startup_tpm_resume.
      • Current QEMU TIS: It would tell in TPMLIB_SetBufferSize() to keep the buffer size at 4kb
      • Current QEMU CRB: It would tell in TPMLIB_SetBufferSize() to keep the buffer size at CRB_CTRL_CMD_SIZE
        • Check: libtpms v0.11 would probably send an error message if the response does not fit into the response buffer; internal state of the TPM 2 may have been modified by the command, though

Problems	libtpms version	swtpm version	QEMU version
none	v0.10	v0.10	pre-PQC
none	v0.10	v0.10	post-PQC
none	v0.10	v0.11	pre-PQC
none	v0.10	v0.11	post-PQC
TIS and CRB restricting size of buffer to 4kb/CRB_CTRL_CMD_SIZE (CMD_SET_BUFFERSIZE -> TPMLIB_SetBufferSize); libtpms would not be able to build a >4kb response and (should) create an error response instead	v0.11	v0.10	pre-PQC
swtpm needs to be allocating 8kb buffers after querying for TPMPROP_TPM2_BUFFER_MAX or query libtpms for its version (>=0.11)	v0.11	v0.10	post-PQC
TIS and CRB restricting size of buffer to 4kb/CRB_CTRL_CMD_SIZE (CMD_SET_BUFFERSIZE -> TPMLIB_SetBufferSize); libtpms would not be able to build a >4kb response and (should) create an error response instead	v0.11	v0.11	pre-PQC
none	v0.11	v0.11	post-PQC

Notes:

• post-PQC QEMU:
  • CRB: needs to advertise chunking capability only if libtpms v0.11 is there, which in turn means that > 4kb s->be_buffer_size is set.
  • TIS: there's only a problem if libtpms v0.11 is being used.
• swtpm v0.10:

  • WIP: Add modifications to swtpm v0.10.x to enable usage with libtpms v0.11 #1090

  • Does swtpm v0.10 need patching if used with libtpms v0.11 with ML-DSA-87?