+Jiewen & Ken (RTMR firmware owner) On 2/3/24 10:46 PM, James Bottomley wrote: > On Sat, 2024-02-03 at 07:57 +0000, Kuppuswamy Sathyanarayanan wrote: >> If the virtual firmware implements TPM support, TCG2 protocol will be >> used for kernel measurements and event logging support. But in CC >> environment, not all platforms support or enable the TPM feature. >> UEFI specification [1] exposes protocol and interfaces used for >> kernel measurements in CC platforms without TPM support. >> >> Currently, the efi-stub only supports the kernel related measurements >> for the platform that supports TCG2 protocol. So, extend it add >> CC measurement protocol (EFI_CC_MEASUREMENT_PROTOCOL) and event >> logging support. Event logging format in the CC environment is the >> same as TCG2. > Why do we have to do this anymore? Given that you're already pushing > patches that map RTMRs to TPM PCRs: > > https://lore.kernel.org/lkml/20240128212532.2754325-4-sameo@xxxxxxxxxxxx/ IMHO, I am not sure whether we need this mapping support . I have already mentioned the same comment in [1]. If we support extension and logging via configFS ABI, why again support PCR mapping? https://lore.kernel.org/lkml/2bd7c80b-9cd8-4450-a410-c3739d224167@xxxxxxxxxxxxxxx/ [1] > > Can't you just add a stub TCG2 driver to EFI that exposes only the > ability to log and measure using this mapping? That way all our > existing code will "just work" without the need to understand anything > about confidential computing or add new code to do the measurement? I am not familiar with the EFI implementation, but I think a new protocol is added to handle future CC extensions (which could deviate from TCG2) and to support platforms that does not support or enable TPM feature. So modifying the TCG2 driver in EFI may not work for the above-mentioned cases. I think the EFI driver part of this support is already merged. Jiewen/Ken may have more comments about this proposal. > > James > -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
