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 chunks
> > is 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.
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
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
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.
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.
>
> > 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.pdf
> >
> > Arun 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
