public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: James Bottomley <jejb@linux.ibm.com>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Xu, Min M" <min.m.xu@intel.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	"Justen, Jordan L" <jordan.l.justen@intel.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH V3 5/9] OvmfPkg/IntelTdx: Measure Td HobList and Configuration FV
Date: Wed, 20 Apr 2022 18:29:15 +0200	[thread overview]
Message-ID: <20220420162915.k234kumo33jgqsg6@sirius.home.kraxel.org> (raw)
In-Reply-To: <56d4a5fab3cda814d1d33a6e3f6987a0313129f5.camel@linux.ibm.com>

  Hi,
 
> > So, no matter what the order is, you'll figure the system got
> > compromised after the fact, when checking the hashes later, and in
> > turn take actions like refusing to hand out secrets to the
> > compromised system.
> 
> Not if the code falsifies the measurement both in the log and to the
> TPM.  That's why the requirement of measured boot is you start with a
> small rom based root of trust, which can't be updated because it's in
> rom.  It measures the next stage (usually PEI) before executing it so
> that the measurement in the TPM would change if the next stage (which
> is often in flash) got compromised, so any tampering is certain to be
> detected and if the compromised code tries to falsify the log, the log
> now wouldn't match the TPM, so it can't evade detection.

How do we establish the root of trust in case of TDX?  We don't have a
real rom in virtual machines ...

Does the tdx firmware measure the firmware code before running it?

Why handle CFV and BFV differently?  Wouldn't it be easier to have the
tdx firmware simply measure the complete OVMF.fd image, given that tdx
doesn't support flash and thus we don't have the code/vars split in the
first place?

The TD HobList is prepared by the hypervisor and present at launch time,
so possibly the tdx firmware could measure it too before handing over
control to the guest?

take care,
  Gerd


  reply	other threads:[~2022-04-20 16:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-17 23:59 [PATCH V3 0/9] Enable RTMR based measurement and measure boot for Td guest Min Xu
2022-04-17 23:59 ` [PATCH V3 1/9] Security: Add HashLibTdx Min Xu
2022-04-17 23:59 ` [PATCH V3 2/9] CryptoPkg: Add SecCryptLib Min Xu
2022-04-18 15:31   ` [edk2-devel] " Michael D Kinney
2022-04-19 11:45     ` Min Xu
2022-04-17 23:59 ` [PATCH V3 3/9] SecurityPkg: Add definition of EFI_CC_EVENT_HOB_GUID Min Xu
2022-04-17 23:59 ` [PATCH V3 4/9] OvmfPkg: Introduce SecMeasurementLib Min Xu
2022-04-17 23:59 ` [PATCH V3 5/9] OvmfPkg/IntelTdx: Measure Td HobList and Configuration FV Min Xu
2022-04-19  6:58   ` Gerd Hoffmann
2022-04-19 11:12     ` Min Xu
2022-04-19 12:49       ` [edk2-devel] " Gerd Hoffmann
2022-04-19 14:06         ` Yao, Jiewen
2022-04-20  8:16           ` Gerd Hoffmann
2022-04-20  9:46             ` Yao, Jiewen
2022-04-20 16:05               ` Gerd Hoffmann
2022-04-20 14:25             ` James Bottomley
2022-04-20 16:29               ` Gerd Hoffmann [this message]
2022-04-20 22:29                 ` Yao, Jiewen
2022-04-21  9:14                   ` Gerd Hoffmann
2022-04-21  9:24                     ` Yao, Jiewen
2022-04-17 23:59 ` [PATCH V3 6/9] OvmfPkg: Add PCDs for LAML/LASA field in CC EVENTLOG ACPI table Min Xu
2022-04-17 23:59 ` [PATCH V3 7/9] MdePkg: Define CC Measure EventLog ACPI Table Min Xu
2022-04-18  1:23   ` Yao, Jiewen
2022-04-18  2:02     ` Min Xu
2022-04-17 23:59 ` [PATCH V3 8/9] OvmfPkg/IntelTdx: Add TdTcg2Dxe Min Xu
2022-04-18  0:00 ` [PATCH V3 9/9] OvmfPkg/IntelTdx: Enable RTMR based measurement and measure boot Min Xu
2022-04-18  1:43 ` [edk2-devel] [PATCH V3 0/9] Enable RTMR based measurement and measure boot for Td guest Yao, Jiewen

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-list 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=20220420162915.k234kumo33jgqsg6@sirius.home.kraxel.org \
    --to=devel@edk2.groups.io \
    /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