From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Xu, Min M" <min.m.xu@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
"Justen, Jordan L" <jordan.l.justen@intel.com>,
Brijesh Singh <brijesh.singh@amd.com>,
Erdem Aktas <erdemaktas@google.com>,
James Bottomley <jejb@linux.ibm.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb
Date: Wed, 1 Sep 2021 08:10:33 +0200 [thread overview]
Message-ID: <20210901061033.auj6v3nnofmcawxc@sirius.home.kraxel.org> (raw)
In-Reply-To: <PH0PR11MB5064085212FC5261798E3DDAC5CD9@PH0PR11MB5064.namprd11.prod.outlook.com>
Hi,
> > I didn't fully investigate what kind of attacks one can do. I'm pretty sure simply
> > making the variable store larger and the spare smaller works, so parts of the
> > variable store are outside the area you are measuring. Not fully sure whenever
> > one can actually reorder the sections to move the varstore completely into the
> > unmeasured area. Or play out other attacks with the same effect, like bloating
> > some header struct.
> >
> > Simply measuring everything (including the spare) will stop all that.
> > Changes wouldn't go unnoticed, period. No ifs and buts. So I'm wondering why
> > you not doing that? Performance? Wouldn't be the first time a performance
> > optimization pokes a hole into a security concept ...
> >
> The measurement value of the CFV (provisioned configuration data) is extended to
> RTMR registers (similar to TPM PCRs). At the same time it is recorded in the TD Event
> log.
> These information will be used by the Attestation server (This is the so-called Attestation).
> In other words there is a known *good* CFV measurement value. Any changes to
> the CFV, for example the layout, the order of the variables, the content of the variables
> will produce a *bad* CFV measurement.
Yes. The attacker would need a varstore with a modified layout being
approved by the attestation server as first step, then he would be able
to modify variables unnoticed in a second step.
So, assuming an attacker isn't able to carry out the first step it
should be all fine in theory. When it comes to security it never hurts
to have another line of defense though, so I would still strongly
recommend to measure the complete varstore (including spare).
At the end of the day it is your call, I'm not going to veto the patch.
But I'll reserve the right to pull a "told you so" in case someone
manages to exploit that some day.
take care,
Gerd
next prev parent reply other threads:[~2021-09-01 6:10 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 2:35 [PATCH V5 0/2] Add Intel TDX support in OvmfPkg/ResetVector Min Xu
2021-08-30 2:35 ` [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb Min Xu
2021-08-30 7:03 ` Gerd Hoffmann
2021-08-31 3:29 ` [edk2-devel] " Min Xu
2021-08-31 5:13 ` Gerd Hoffmann
2021-08-31 6:17 ` Min Xu
2021-08-31 10:21 ` Gerd Hoffmann
2021-09-01 5:18 ` Min Xu
2021-09-01 6:10 ` Gerd Hoffmann [this message]
2021-09-01 6:57 ` Ard Biesheuvel
2021-09-01 7:19 ` Min Xu
2021-09-01 7:44 ` Gerd Hoffmann
2021-09-01 8:59 ` Yao, Jiewen
2021-09-01 16:53 ` James Bottomley
2021-09-01 19:19 ` Andrew Fish
2021-09-10 17:03 ` Erdem Aktas
2021-08-30 2:35 ` [PATCH V5 2/2] OvmfPkg/ResetVector: Enable Intel TDX in ResetVector of Ovmf Min Xu
2021-08-30 7:40 ` Gerd Hoffmann
2021-08-31 3:09 ` [edk2-devel] " Min Xu
2021-08-31 5:35 ` Gerd Hoffmann
2021-09-02 0:05 ` Min Xu
2021-09-02 7:18 ` Gerd Hoffmann
2021-09-02 7:49 ` Min Xu
2021-09-03 3:03 ` Yao, Jiewen
2021-09-03 5:39 ` Gerd Hoffmann
2021-09-09 13:54 ` Min Xu
2021-09-10 8:19 ` Gerd Hoffmann
2021-09-14 3:54 ` Yao, Jiewen
2021-09-11 1:17 ` Erdem Aktas
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=20210901061033.auj6v3nnofmcawxc@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