RE: [PATCH v4 4/7] tpm: tpm_tis: Fix expected bit handling and send all bytes in one shot without last byte in exception

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Tue, Mar 31, 2020 at 02:32:04PM +0300, amirmizi6@xxxxxxxxx wrote:
> > From: Amir Mizinski <amirmizi6@xxxxxxxxx>
> > 
> > Today, actual implementation for send massage is not correct. We check 
> > and loop only on TPM_STS.stsValid bit and next we single check 
> > TPM_STS.expect bit value.
> > TPM_STS.expected bit shall be checked in the same time of 
> > TPM_STS.stsValid, and should be repeated until timeout_A.
> > To aquire that, "wait_for_tpm_stat" function is modified to 
> > "wait_for_tpm_stat_result". this function read regulary status 
> > register and check bit defined by "mask" to reach value defined in "mask_result"
> > (that way a bit in mask can be checked if reached 1 or 0).
> > 
> > Respectively, to send message as defined in 
> >  TCG_DesignPrinciples_TPM2p0Driver_vp24_pubrev.pdf, all bytes should be 
> > sent in one shot instead of sending last byte in exception.
> > 
> > This improvment was suggested by Benoit Houyere.

>Use suggested-by tag.

>Also if something is not correct, please provide a fixes tag.

> You are speaking now in theoretical level, which we don't really care that much. Is this causing you real issues? If the answer is yes, please report them. If the > >answer is no, we don't need this.

> /Jarkko

I2C TPM specification introduce CRC calculation on TPM command bytes. CRC calculation take place from last byte acquired to  TPM_STS.expected bit reset (=0) .It introduces latency and actual incorrect implementation becomes visible now under I2C on the contrary before that's all. 
The case where TPM keeps TPM_STS.expected bit set  with TPM_STS.stsValid set after last byte reception is possible and is not an issue. It's not theoretical level, it's practical level now.






[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux