Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs

[Dan Williams <dan.j.williams@intel.com>]

Xing, Cedric wrote:
> On 1/22/2024 2:32 PM, Dan Williams wrote:
> > Xing, Cedric wrote:
> > [..]
> >>> So, yes, the mapping should be allowed to specified by the low-level
> >>> driver, but at the same time every vendor should not reinvent their own
> >>> enumeration method when we have EFI for that.
> >>
> >> Given PCR->RTMR mapping is static, I just wonder why it needs to be kept
> >> in kernel. Given that PCRs can never be 1:1 mapped to RTMRs, and that
> >> TDX quotes are never TPM quotes, applications used to extend PCRs would
> >> have to be changed/recompiled. Then wouldn't it suffice to define the
> >> mappings as macros in an architecture specific header file?
> > 
> > I think something is wrong if applications are exposed to the PCR->RTMR
> > mapping thrash. I would hope / expect that detail is hidden behind a TPM
> > proxy layer sitting in front of this mapping on behalf of TPM-client
> > applications.
> 
> Hi Dan,
> 
> My apology for the confusion! I think we are talking about 2 different 
> scenarios - (1) this patch alone; and (2) this patch + vTPM.
> 
> Scenario 1: This patch provides RTMR access only. My assumption is, 
> there are existing application (and/or kernel modules) that extend to 
> PCRs today and would like to work in TDs where only RTMRs are available. 
> Changes are of course necessary in those applications as TPMs/PCRs are 
> no longer available, but from security perspective they would like to 
> keep the same activity log and just change to use RTMRs (in lieu of 
> PCRs) as the secure storage. Hence a PCR->RTMR mapping is necessary and 
> must be agreed upon by all those applications and relying parties. IIUC, 
> this is the intention of having PCR->RTMR mapping config maintained by 
> the kernel, as proposed by Sam O. originally.
> 
> Scenario 2: A vTPM is implemented on top of this patch, in which case 
> the existing applications don't have to change as they can continue 
> extending to the same PCRs, which will then be emulated by the 
> underlying vTPM implementation. PCR->RTMR mapping in this scenario is 
> obviously internal to the vTPM and I agree with you completely that it 
> should be hidden inside the vTPM.
> 
> My comment in my previous email was regarding Scenario 1. I hope the 
> clarification above helps.

Got it, yes, makes sense.

I think the only use cases in scenario 1 are either kernel internal or
the backend of the vTPM implementation.

Even though RTMR is cross-platform it is not universal, so vTPM remains
the universal solution for most applications.