[Cc'ing Ken Goldman, Monty Wiseman, and Dave Safford] On Tue, 2020-04-14 at 19:50 +0800, Tianjia Zhang wrote: > Because ima_pcr_extend() to operate the TPM chip, this process is > very time-consuming, for IMA, this is a blocking action, especially > when the TPM is in self test state, this process will block for up > to ten seconds. > > Because the return result of ima_pcr_extend() is of no concern to IMA, > it only affects the audit of IMA, so this patch use async_schedule() > to asynchronously perform the ima_pcr_extend() operation and do an > audit operation at the end. > > In a vtpm scenario, I added the measure policy of BPRM and MMAP to > compare the efficiency before and after applying the patch. The results > show that the overall startup efficiency of conventional processes can > be increased by 5% to 10%. I believe this efficiency increase It will > be more obvious on real hardware tpm. Yes, we're fully aware that extending the TPM PCR takes a long time. That is the reason for a lot of Nayna Jain's and my work on improving the TPM performance. At one point, I implemented queueing the measurements without waiting for the measurements to extend the TPM. The performance was absolutely amazing, but not waiting for the TPM extend to complete violates the trusted boot principle of measuring and extending the TPM PCR before use. Secondly, the IMA measurement list order and the order in which the measurements extend the TPM is really important in order to be able to validate the IMA measurement list against the TPM PCR quote. One solution that we've considered is batching the measurements, so that the TPM PCR is extended with the hash of the batched measurements, instead of each measurement. The IMA measurement list would continue to contain the individual measurements, but would also need to indicate start/stop of the batched measurement group. None of this is trivial. Mimi
