On 3/13/26 3:35 PM, Arun Menon wrote:
Hi Stefan, Thank you for taking a look into this. On Thu, Mar 12, 2026 at 10:36:29AM -0400, Stefan Berger wrote:On 3/12/26 12:16 AM, Arun Menon wrote:The move to Post Quantum Cryptography (PQC) changes how we manage memory buffers. Unlike classic crypto algorithms like RSA or ECC which used small keys and signatures, PQC algorithms require larger buffers. The new version of TCG TPM v185 (currently under review [1]) supports sending data/commands in chunks for the CRB (Command Response Buffer) interface. This is in line with the initiative to support PQC algorithms. This series implements the logic to send and receive data from the linux guest to the TPM backend in chunks, thereby allowing the guest to send larger data buffers. We introduce 2 new control registers called nextChunk and crbRspRetry that will control the START. We also add the CRB Interface Identifier called CapCRBChunk that is set to 1 indicating that the device supports chunking. The default maximum chunk/buffer size is 3968 (4096 - 128) bytes. During a send operation, the guest driver places data in the CRB buffer and signals nextChunk for each segment until the final chunk is reached. Upon receiving the START signal, QEMU appends the final chunk to its internal buffer and dispatches the complete command to the TPM backend. For responses, the backend's output is buffered. The guest consumes the first chunk once the START bit is cleared. Subsequent chunks are retrieved by the guest toggling the nextChunk bit, which advances the internal buffer offset and populates the CRB data window. For this to work, the linux guest tpm driver will also have to a) probe if CRB chunking is supported b) send data in chunks if the command length exceeds the chunk size. c) receive data in chunks by sending a nextChunk signal and accumulate.At present, VM live migration during a tpm command execution in chunksis not supported. We intend to add support for TIS interface in.. and also VM suspend/resume. Do you intend to support these? The problem will be state incompatibility with previous QEMU versions then since we now need to save the additional (bytes in the new) byte buffer(s) and possibly the new control registers' contents.Yes I would like to support suspend/resume along with migration. And yes, I will start by saving those buffer information in the VMstate subsection.
If we bump up the version from state v0 to v1, can v0 capable devices still read the state and discard data that are for v1?
I am not sure whether the following is possible - the is maintaining backwards compatibility as much as possible: - if the CRB OS driver never touched the chunking during the transaction, write v0 state - if the CRB OS driver touched the chunking feature during the transaction, write v1 state
I was looking whether we can still use qemu_put_byte() etc. but was missing the .save interface from DeviceClass for example.
Also, I am working on the linux driver part. The logic is more or less the same; 2 buffers, accumulating data, and send/receive based on the new register bit.Thanks for also thinking of the TIS support. I guess we will have the same issue there then with state incompatibilities even though with the TIS it should just be a matter of just using a bigger buffer. Theoretically we could write a 4096 byte buffer to the state if up to 4kb are held there and switch to a .version_id = 1 state for bigger buffer size, but then we could migrate to an older version of QEMU and find that it cannot do PQC transactions (anymore) due to older version of TIS there (I guess migration between major versions of QEMU is supported with all kinds of machines). Also, nothing will prevent one from running a PQC-enabled swtpm+libtpms with an older version of QEMU but one will find out if transactions don't succeed (assuming Linux TPM driver can handle it) because the QEMU TIS buffer is too small.Yes the same issue will come with TIS. Although changing the buffer size TPM_TIS_BUFFER_MAX to 8192 (for now) would be a one liner change, but handling the state, for migration and other cases will be tricky like you mentioned for both crb and tis. If I understand correctly, We need to know whether a) swtpm OR the TPM backend supports chunking
I am collecting these buffer-related issue here considering combinations of different versions of libtpms, swtpm, and QEMU (not considering Linux driver). The table is probably the best for now to see the problematic combinations on the lower layers:
https://github.com/stefanberger/swtpm/issues/1076
b) does the underlying machine type of qemu suport chunking.
I am not sure if swtpm can set a capability bit if chunking is
supported. If we can do that, then QEMU can probe the backend and get
swtpm (v0.11 and via backport also v0.10.x) will simply work with a 8kb buffer once libtpms (v0.11) tells it that it can support up to 8 kb buffers.
that information. But that will not be sufficient. To decide whether chunking is actually allowed based on the underlying machine type we might have to add a prop bool for the specific machine type.
Are you referring the CRB capability bit that advertises the chunking capability? I think a good sign that chunking should be supported by CRB (set the chunking-supported bit CapCRBChunk) is that the buffer queried for from swtpm indicates > 4kb (s->be_buffer_size = tpm_backend_get_buffer_size(s->tpmbe) ). If the buffer size is still 4kb it probably should not advertise the chunking capability -- hadn't thought of this while reviewing the patches, but ... you may want to add this in the code.
If both of them (a and b) are true, only the linux probing will return true for chunking. Thus linux will not send the huge buffers in the first place, or even try to copy data in the subsections during migration with the .needed function. Please correct me if I am wrong.
I am not sure about all the details yet, either.
the future. The included test demonstrates functional correctness for standard buffer sizes. However, validation of PQC-sized payloads was performed via manual buffer-size overrides.[1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdfArun Menon (5): hw/tpm: Add TPM CRB chunking fields hw/tpm: Refactor CRB_CTRL_START register access hw/tpm: Add internal buffer state for chunking hw/tpm: Implement TPM CRB chunking logic test/qtest: Add test for tpm crb chunking hw/tpm/tpm_crb.c | 167 +++++++++++++++++++++++++++---- include/hw/acpi/tpm.h | 5 +- tests/qtest/tpm-crb-swtpm-test.c | 10 ++ tests/qtest/tpm-util.c | 106 +++++++++++++++++--- tests/qtest/tpm-util.h | 5 + 5 files changed, 256 insertions(+), 37 deletions(-)Regards, Arun Menon
