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?
  • Merge PR [3] Add support for ML-KEM and ML-DSA keys to swtpm_setup #1099

• Test cases for ML-DSA and ML-KEM in default-v2 profile

• Add state with null, default-v1, and default-v2 profiles created by libtpms v0.11 to tests/data/tpm2state8 and extend test case the_tpm2_save_load_state_2

• 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 to 8kb in libtpms v0.11.
    • If TPM produces a response that is bigger than the TPMLIB_SetBufferSize()-negotiated buffer size, then it will truncate the buffer. QEMU TIS and SPAPT use 4kb buffer, CRB 3968 bytes. There's no response that use close to 4kb. The biggest response may currently be from TPM2_ContextSave, which is ~2.5kb or so.
    • 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).

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

    • QEMU uses the TPMLIB_SetBufferSize()-negotiated buffer size and swtpm always uses the maximum buffer size that libtpms would support and can therefore receive all the packets from QEMU.
    • When swtpm gets a response from libtpms, then that response is limited to the buffer size that was negotiated with QEMU (4096 for TIS & SPAPR, 3968 bytes for CRB) and swtpm then just writes this response into the socket to send it to QEMU, which has a buffer that can receive any response packet from libtpms (as negotiated)
      • It's necessary to backport a patch to swtpm v0.10 so that it queries libtpms for TPM2_BUFFER_MAX and allocates a bigger buffer.

  • 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.
      • 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 (3968 bytes)

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 or truncate the response	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 or truncate the response	v0.11	v0.11	pre-PQC
none	v0.11	v0.11	post-PQC

Notes:

• If libtpms v0.11 + swtpm v0.11 + pre-PQC QEMU are used then the user may create an ML-DSA-87 key but won't be able to call TPM_ContextSave or TPM_Sign on it since the response is too long because pre-PQC QEMU has limited any response to max. 4096 bytes (TIS); other such new commands related to PQC keys exist where the limited buffer size either prevents the commands from being sent or the response from being received
• None of the the (inspected) Linux TPM drivers will read TPM packets into a buffer that is not big enough to hold the whole response packet (good)
• post-PQC QEMU:
  • 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.
  • QEMU TIS: there's only a problem if libtpms v0.11 is being used since it requires a bigger buffer supported by QEMU TIS
• swtpm v0.10:
  • It is necessary for it to use 8kb buffer: Add modifications to swtpm v0.10.x to enable usage with libtpms v0.11 #1090

[LordGrimmauld]

While taking a casual stab at migrating swtpm from fuse2 to fuse3 in nixpkgs i came across a few issues that should probably not make it into a 0.11 release.

• src/swtpm/utils.c has a broken format string. Likely just a typo with a missing %s:

  swtpm/src/swtpm/utils.c

  Lines 251 to 252 in 5a89ef3

  	logprintf(STDERR_FILENO, "fcntl for F_GETPATH failed: %\n",
  	strerror(errno));

  
  Somehow this doesn't fail to compile with gcc, but clang complains about it which is how i noticed
• systemd varlink things should probably not be built on non-linux systems. This exploded because src/swtpm/sd-notify.c uses SOCK_CLOEXEC, which is not available e.g. on darwin.

  swtpm/src/swtpm/sd-notify.c

  Line 54 in 5a89ef3

  fd = socket(AF_UNIX, SOCK_DGRAM | SOCK_CLOEXEC, 0);

  
  I am not sure how hard a conditional for this in build system would be, but as it stands it is broken, and only really makes sense for linux anyways.
• The initializer lists for all schemedata fields in src/swtpm_setup/swtpm.c fail on clang due to incompatible pointer casts. The type inference knows what it needs to do, it should be possible to just omit the (unsigned char[SCHEMEDATA_SIZE]) part, at least that makes the compiler happy for me...

  swtpm/src/swtpm_setup/swtpm.c

  Lines 622 to 624 in 5a89ef3

  	.schemedata = (unsigned char[SCHEMEDATA_SIZE]) {
  	AS2BE(TPM2_ALG_NULL), AS2BE(TPM2_ECC_NIST_P256), AS2BE(TPM2_ALG_NULL)
  	},

I am aware clang, darwin and nix is kind of a weird configuration, but i do believe it makes sense to report these issues before a 0.11 release happens considering i already found these issues.

[stefanberger]

Thanks for the reports.

1. I did not see the format string error with clang 21.1.8 (6ubuntu) -- it seems to have compiled the swtpm/utils.c. Nevertheless, I will fix this of course.
2. The SOCK_CLOEXEC is not necessary. I will remove it.
3. It looks like in this case the (unsigned char[SCHEMEDATA_SIZE]) can be removed entirely for both gcc and clang.

Thanks.

[stefanberger]

@LordGrimmauld Please have a look at PR #1127 . If you want I can add your Reported-by tag to the patches. Let me know. Otherwise I will merge it soon.