Page MenuHomeFreeBSD

tpm20: Support partial reads
ClosedPublic

Authored by jhibbits on May 9 2024, 3:31 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Dec 9, 7:01 AM
Unknown Object (File)
Nov 27 2024, 2:59 AM
Unknown Object (File)
Nov 25 2024, 8:25 PM
Unknown Object (File)
Nov 24 2024, 1:20 AM
Unknown Object (File)
Nov 23 2024, 4:48 PM
Unknown Object (File)
Nov 23 2024, 10:35 AM
Unknown Object (File)
Nov 22 2024, 6:56 AM
Unknown Object (File)
Nov 7 2024, 11:06 AM
Subscribers

Details

Summary

In some cases the TPM utilities may read only a partial block, instead
of a full block. If a new command starts while in the middle of a read
it may cause the TPM to go catatonic and no longer respond to SPI.

Obtained from: Juniper Networks, Inc.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/dev/tpm/tpm20.c
87

We need to clear the part of the buffer that we've just read here.
Otherwise you could potentially leak the contents to another caller.

sys/dev/tpm/tpm20.c
87

I'm fine clearing it out, but I'm confused how that would happen. We're already adjusting the offset for the next read, so nobody should get "stale" data, only the next data.

sys/dev/tpm/tpm20.c
87

Oh, good point.
And we can't really get stale data after the current reader is done with reading, since the sc->total_length is going to be either 0, or the response length of the subsequent command.

One last thing then. Could you please also update tpm_crb.c, so that it's not broken with this commit.
Just add sc->total_length = bytes_available; at the end of tpmcrb_transmit.

This revision is now accepted and ready to land.May 9 2024, 5:46 PM
This revision was automatically updated to reflect the committed changes.