From: "Xing, Cedric" <cedric.xing@intel.com>
To: Dan Williams <dan.j.williams@intel.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
Qinkun Bao <qinkun@google.com>, Samuel Ortiz <sameo@rivosinc.com>,
"Lu, Ken" <ken.lu@intel.com>
Cc: Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs
Date: Tue, 23 Jan 2024 10:48:00 -0800 [thread overview]
Message-ID: <14dffda2-f413-4304-9932-3ac8ddfb30e4@intel.com> (raw)
In-Reply-To: <65aeecea827f0_37ad2948@dwillia2-xfh.jf.intel.com.notmuch>
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.
-Cedric
next prev parent reply other threads:[~2024-01-23 18:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-14 22:35 [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI Samuel Ortiz
2024-01-14 22:35 ` [RFC PATCH v1 1/4] tsm: Runtime measurement register support Samuel Ortiz
2024-01-14 22:35 ` [RFC PATCH v1 2/4] tsm: Add RTMRs to the configfs-tsm hierarchy Samuel Ortiz
2024-01-14 22:35 ` [RFC PATCH v1 3/4] tsm: Allow for mapping RTMRs to TCG TPM PCRs Samuel Ortiz
2024-01-16 22:28 ` Kuppuswamy Sathyanarayanan
2024-01-17 1:24 ` Dan Williams
2024-01-17 3:35 ` Kuppuswamy Sathyanarayanan
2024-01-21 16:31 ` Samuel Ortiz
2024-01-22 2:13 ` Qinkun Bao
2024-01-22 2:23 ` Yao, Jiewen
2024-01-22 7:49 ` Samuel Ortiz
2024-01-22 20:10 ` Dan Williams
2024-01-22 21:58 ` Xing, Cedric
2024-01-22 22:32 ` Dan Williams
2024-01-23 18:48 ` Xing, Cedric [this message]
2024-01-23 19:14 ` Dan Williams
2024-01-23 20:59 ` Kuppuswamy Sathyanarayanan
2024-01-26 16:55 ` Dionna Amalie Glaze
2024-01-23 1:22 ` Yao, Jiewen
[not found] ` <90EDEF2B-DB43-413F-840E-3268977FDBD0@google.com>
2024-01-22 7:46 ` Samuel Ortiz
2024-01-22 15:04 ` Kuppuswamy Sathyanarayanan
2024-01-22 22:12 ` Kuppuswamy Sathyanarayanan
2024-01-14 22:35 ` [RFC PATCH v1 4/4] tsm: Allow for extending and reading configured RTMRs Samuel Ortiz
2024-01-16 20:44 ` [RFC PATCH v1 0/4] tsm: Runtime measurement registers ABI Dan Williams
2024-01-18 3:35 ` biao.lu
2024-01-18 17:42 ` Dionna Amalie Glaze
2024-01-18 19:20 ` Dan Williams
2024-01-21 18:11 ` Samuel Ortiz
2024-01-21 19:15 ` Dan Williams
2024-01-22 22:12 ` Xing, Cedric
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14dffda2-f413-4304-9932-3ac8ddfb30e4@intel.com \
--to=cedric.xing@intel.com \
--cc=dan.j.williams@intel.com \
--cc=jiewen.yao@intel.com \
--cc=ken.lu@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=qinkun@google.com \
--cc=sameo@rivosinc.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).