[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65b010121635d_37ad294f3@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 23 Jan 2024 11:14:26 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: "Xing, Cedric" <cedric.xing@...el.com>, Dan Williams
<dan.j.williams@...el.com>, "Yao, Jiewen" <jiewen.yao@...el.com>, Qinkun Bao
<qinkun@...gle.com>, Samuel Ortiz <sameo@...osinc.com>, "Lu, Ken"
<ken.lu@...el.com>
CC: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>,
"linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs
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.
Powered by blists - more mailing lists