[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65aeecea827f0_37ad2948@dwillia2-xfh.jf.intel.com.notmuch>
Date: Mon, 22 Jan 2024 14:32:10 -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:
[..]
> > 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.
Powered by blists - more mailing lists