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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.