linux-kernel - Re: [PATCH v1] efi/libstub: Add Confidential Computing (CC) measurement support

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]

Message-ID: <7357618f02b87786f06f3e10b50f1247f328f07a.camel@HansenPartnership.com>
Date: Mon, 05 Feb 2024 08:20:27 +0000
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>,
  Ard Biesheuvel <ardb@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org, "Yao, Jiewen"
	 <jiewen.yao@...el.com>, "Lu, Ken" <ken.lu@...el.com>
Subject: Re: [PATCH v1] efi/libstub: Add Confidential Computing (CC)
 measurement support

On Sun, 2024-02-04 at 12:27 -0800, Kuppuswamy Sathyanarayanan wrote:
> +Jiewen & Ken (RTMR firmware owner)
> 
> On 2/3/24 10:46 PM, James Bottomley wrote:
> > On Sat, 2024-02-03 at 07:57 +0000, Kuppuswamy Sathyanarayanan
> > wrote:
> > > If the virtual firmware implements TPM support, TCG2 protocol
> > > will be used for kernel measurements and event logging support.
> > > But in CC environment, not all platforms support or enable the
> > > TPM feature. UEFI specification [1] exposes protocol and
> > > interfaces used for kernel measurements in CC platforms without
> > > TPM support.
> > > 
> > > Currently, the efi-stub only supports the kernel related
> > > measurements for the platform that supports TCG2 protocol. So,
> > > extend it add CC measurement protocol
> > > (EFI_CC_MEASUREMENT_PROTOCOL) and event logging support. Event
> > > logging format in the CC environment is the same as TCG2.
> >  
> > Why do we have to do this anymore?  Given that you're already
> > pushing patches that map RTMRs to TPM PCRs:
> > 
> > https://lore.kernel.org/lkml/20240128212532.2754325-4-sameo@rivosinc.com/
> 
> IMHO, I am not sure whether we need this mapping support . I have
> already mentioned the same comment in [1]. If we support extension
> and logging via configFS ABI, why again support PCR mapping?
> 
> https://lore.kernel.org/lkml/2bd7c80b-9cd8-4450-a410-c3739d224167@linux.intel.com/

Well, the point is if it can be done, you can push the measurement and
logging all the way down into the TCG driver and not have to modify any
upper layer code at all (so less chance of introducing bugs).  It would
be a single change instead of patching everywhere there's a
measurement.

> > Can't you just add a stub TCG2 driver to EFI that exposes only the
> > ability to log and measure using this mapping?  That way all our
> > existing code will "just work" without the need to understand
> > anything about confidential computing or add new code to do the
> > measurement?
> 
> I am not familiar with the EFI implementation, but I think a new
> protocol is added to handle future CC extensions (which could deviate
> from TCG2)

OK, but you could add a new driver for just that functionality only
when you actually deviate and handle all of the current functionality
in the non-deviating TCG driver.  Nothing forbids a feature from having
multiple driver attachments.

James

>  and to support platforms that does not support or enable TPM
> feature. So modifying the TCG2 driver in EFI may not work for the
> above-mentioned cases. I think the EFI driver part of this support
> is already merged.
> 
> Jiewen/Ken may have more comments about this proposal.