public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Longlong Yang" <longlong.yang@intel.com>
To: "Ni, Ray" <ray.ni@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Dong, Eric" <eric.dong@intel.com>,
	"Kumar, Rahul1" <rahul1.kumar@intel.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	"Xu, Min M" <min.m.xu@intel.com>,
	"Zhang, Qi1" <qi1.zhang@intel.com>
Subject: Re: [PATCH V3 1/1] UefiCpuPkg: Extend measurement of microcode patches to TPM
Date: Tue, 14 Dec 2021 03:02:11 +0000	[thread overview]
Message-ID: <DM4PR11MB5456964F7EFBEC721D4F0A9AF0759@DM4PR11MB5456.namprd11.prod.outlook.com> (raw)
In-Reply-To: <BN0PR11MB569675CE35FB32CD992DFE8B8C759@BN0PR11MB5696.namprd11.prod.outlook.com>

Hi Ray,

The order is required by the hash function.
By measuring an object, we first need to get the hash or the digest of that object, and then extend the hash/digest or measurement to TPM device. If there are more than one microcode patches applied to CPU, we need to measure all of those patches. My design on measuring multiple microcode patches is that we first pack those patches into a single binary blob, and then measure the binary blob by calling TpmMeasureAndLogData function. In TpmMeasureAndLogData function, the hash of binary blob will be calculated. If the order got changed, then the hash will change too, and then the attestation will be impacted. Therefore we need make sure if microcode didn't get updated, then the hash/digest should the same every time we measure them. So we should sort the patches to make sure the binary blob is device specific same. 

BRs
Longlong

-----Original Message-----
From: Ni, Ray <ray.ni@intel.com> 
Sent: Tuesday, December 14, 2021 9:57 AM
To: Yang, Longlong <longlong.yang@intel.com>; devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Xu, Min M <min.m.xu@intel.com>; Zhang, Qi1 <qi1.zhang@intel.com>
Subject: RE: [PATCH V3 1/1] UefiCpuPkg: Extend measurement of microcode patches to TPM

> +
> +  //
> +  // The order matters when packing all applied microcode patches to a single binary blob.
> +  // Therefore it is a must to do sorting before packing.
> +  // NOTE: We assumed that the order of address of every microcode 
> + patch in RAM is the same  // with the order of those in the 
> + Microcode Firmware Volume in FLASH. If any future updates  // made this assumption untenable, then needs a new solution to measure microcode patches.
> +  //

Can you explain the above comments?
If you only measure the microcode which will be applied to CPU, why do you care about the order?

      reply	other threads:[~2021-12-14  3:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1639394321.git.longlong.yang@intel.com>
2021-12-13 11:19 ` [PATCH V3 1/1] UefiCpuPkg: Extend measurement of microcode patches to TPM longlong.yang
2021-12-14  1:56   ` Ni, Ray
2021-12-14  3:02     ` Longlong Yang [this message]

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=DM4PR11MB5456964F7EFBEC721D4F0A9AF0759@DM4PR11MB5456.namprd11.prod.outlook.com \
    --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