On Sun, 2024-02-04 at 12:27 -0800, Kuppuswamy Sathyanarayanan wrote: > +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/ Well, the point is if it can be done, you can push the measurement and logging all the way down into the TCG driver and not have to modify any upper layer code at all (so less chance of introducing bugs). It would be a single change instead of patching everywhere there's a measurement. > > 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) OK, but you could add a new driver for just that functionality only when you actually deviate and handle all of the current functionality in the non-deviating TCG driver. Nothing forbids a feature from having multiple driver attachments. James > 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.
