From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: "kraxel@redhat.com" <kraxel@redhat.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
Ard Biesheuvel <ardb@kernel.org>,
"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>,
Erdem Aktas <erdemaktas@google.com>,
James Bottomley <jejb@linux.ibm.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
"Yamahata, Isaku" <isaku.yamahata@intel.com>
Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c
Date: Wed, 25 Aug 2021 16:28:51 +0000 [thread overview]
Message-ID: <PH0PR11MB48851A2EEA36A1CBCE3E31E58CC69@PH0PR11MB4885.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20210825145143.rp3gqcqzd6fktkjk@sirius.home.kraxel.org>
Comment below:
> -----Original Message-----
> From: kraxel@redhat.com <kraxel@redhat.com>
> Sent: Wednesday, August 25, 2021 10:52 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb@kernel.org>; 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>;
> Erdem Aktas <erdemaktas@google.com>; James Bottomley
> <jejb@linux.ibm.com>; Tom Lendacky <thomas.lendacky@amd.com>
> Subject: Re: [edk2-devel] [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c
>
> Hi,
>
> > > > In TDVF design, we choose the use TDX defined initial pointer to pass
> > > > the initial memory information - TD_HOB, instead of CMOS region.
> > > > Please help me understand what is the real concern here.
> > >
> > > Well, qemu settled to the fw_cfg design or a number of reasons. It is
> > > pretty flexible for example. The firmware can ask for the information
> > > it needs at any time and can store it as it pleases.
> > >
> > > I'd suggest to not take it for granted that an additional alternative
> > > way to do basically the same thing will be accepted to upstream qemu.
> > > Submit your patches to qemu-devel to discuss that.
> >
> > [Jiewen] I think Intel Linux team is doing that separately.
>
> Please ask them to send the patches. Changes like this obviously need
> coordination and agreement between qemu and edk2 projects, and ideally
> both guest and host code is reviewed in parallel.
[Jiewen] Sure.
I add Yamahata, Isaku <isaku.yamahata@intel.com> here. He can help answer the KVM/QEMU related question.
Some reference for QEMU:
https://lists.nongnu.org/archive/html/qemu-devel/2021-07/msg01682.html
in patchwork, https://patchwork.kernel.org/project/qemu-devel/cover/cover.1625704980.git.isaku.yamahata@intel.com/
And I guess you probably need look at the KVM as well.
>
> > > Most fw_cfg entries are constant anyway, so we can easily avoid a second
> > > call by caching the results of the first call if that helps TDVF.
> >
> > [Jiewen] It is possible. We can have multiple ways:
> > 1) Per usage cache. However, that means every driver need use its own way to
> cache the data, either PCD or HOB in PEI phase. Also driver A need to know
> clearly that driver B will use the same data, then it will cache otherwise it will
> not cache. I treat it as a huge burden for the developer.
> > 2) Always cache per driver. That means every driver need follow the same
> pattern: search cache, if miss the get it and cache it. But it still cannot guarantee
> the data order in different path architecturally.
> > 3) Always cache in one common driver. One driver can get all data one time
> and cache them. That can resolve the data order problem. I am not sure if that is
> desired. But I cannot see too much difference between passing data at entry
> point.
>
> Not investigated yet. seabios fw_cfg handling is close to (3) for small
> items (not kernel or initrd or other large data sets) so I think I would
> look into that first.
[Jiewen] I don't think it is urgent at this moment.
>
> > > > Using HOB in the initial pointer can be an alternative pattern to
> > > > mitigate such risk. We just need measure them once then any component
> > > > can use that. Also, it can help the people to evaluate the RTMR hash
> > > > and TD event log data for the configuration in attestation flow,
> > > > because the configuration is independent with the code execution flow.
> > >
> > > Well, it covers only the memory map, correct? All other configuration
> > > is still loaded from fw_cfg. I can't see the improvement here.
> >
> > [Jiewen] At this point of time, memory map is the most important
> > parameter in the TD Hob, because we do need the memory information at
> > the TD entrypoint. That is mandatory for any TD boot.
>
> Well, I can see that the memory map is kind of special here because you
> need that quite early in the firmware initialization workflow.
[Jiewen] That is correct.
>
> > The fw_cfg is still allowed in the TDVF design guide, just because we
> > feel it is a burden to convert everything suddenly.
>
> What is the longer-term plan here?
>
> Does it make sense to special-case the memory map?
>
> If we want handle other fw_cfg items that way too later on, shouldn't we
> better check how we can improve the fw_cfg interface so it works better
> with confidential computing?
[Jiewen] So far, my hope is to limit the fw_cfg as much as possible.
My worry is that we have to measure fw_cfg everywhere. If we miss one place, it will be a completeness vulnerability for trusted computing.
I also think if we can add measurement code inside of fw_cfg get function.
Then we need improve the FwCfg API - Current style: QemuFwCfgSelectItem() + QemuFwCfgReadxxx() is not friendly for measurement. For example, we can combine them and do QemuFwCfgSelectRead ().
The QemuFwCfgWritexxx() interface may also bring inconsistency issue. If we use this API, we have 2 copy data. One is in TDVF (trusted), and the other is in VMM/QEMU (untrusted). What if the VMM modifies its untrusted copy?
What I can see is many potential attack surfaces. :-(
>
> > > How do you pass the HOB to the guest? Copy data to guest ram? Map a
> > > ro page into guest address space? What happens on VM reset?
>
> > [Jiewen] Yes, VMM will prepare the memory information based upon TDVF
> > metadata. The VMM need copy TD HOB data to a predefined memory region
> > according to TDVF metadata.
>
> Is all that documented somewhere? The TVDF design overview focuses on
> the guest/firmware side of things, so it isn't very helpful here.
[Jiewen] The TDX architecture define this architecture way, the RCX/R9 refer is the pointer.
We have a couple of TDX document at https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-module-1eas-v0.85.039.pdf
Section 8.1 defines the VCPU init state. The RCX/R8 hold the launch parameter.
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.pdf
Section 4.1.2 describes the TD HOB usage for RCX/R8. Section 7 adds more detail on memory map reporting.
Please let me know if you need any other information.
>
> Did I mention posting the qemu patches would be a good idea?
>
> > I don't fully understand the VM reset question. I try to answer. But if that is not
> what you are asking, please clarify.
>
> What happens if you reboot the guest?
>
> On non-TDX guests the VM will be reset, the cpu will jump to the reset
> vector (executing from rom / flash), firmware will re-initialize
> everything and re-load any config information it needs from fw_cfg
>
> > This action that VMM initiates TD HOB happens when the VMM launches a TD
> guest.
> > After that the region will becomes TD private memory and own by TD. VMM
> can no longer access it (no read/no write).
> > If VM reset, then this memory is gone.
> > If VMM need launch a new TD, the VMM need initiate the data again.
>
> Sounds like reset is not supported, you need to stop and re-start the
> guest instead. Is that correct?
[Jiewen] That is correct. In our definition, reset == stop + restart.
>
> take care,
> Gerd
next prev parent reply other threads:[~2021-08-25 16:29 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-12 11:56 [PATCH 00/23] Enable Intel TDX in OvmfPkg (SEC/PEI) Min Xu
2021-08-12 11:56 ` [PATCH 01/23] OvmfPkg: Add Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb Min Xu
2021-08-12 11:56 ` [PATCH 02/23] OvmfPkg/Sec: Update the check logic in SevEsIsEnabled Min Xu
2021-09-11 1:13 ` Erdem Aktas
2021-09-13 3:04 ` Min Xu
2021-08-12 11:56 ` [PATCH 03/23] OvmfPkg/ResetVector: Enable Intel TDX in ResetVector of Ovmf Min Xu
2021-09-11 1:14 ` Erdem Aktas
2021-09-13 6:06 ` Min Xu
2021-09-14 2:16 ` Erdem Aktas
2021-08-12 11:56 ` [PATCH 04/23] MdePkg: Add Tdx.h Min Xu
2021-08-12 20:52 ` Michael D Kinney
2021-08-12 22:57 ` Min Xu
2021-08-12 11:56 ` [PATCH 05/23] MdePkg: Add TdxProbeLib to probe Intel Tdx Min Xu
2021-08-16 9:43 ` [edk2-devel] " Gerd Hoffmann
2021-08-17 0:14 ` Min Xu
2021-08-17 8:20 ` Gerd Hoffmann
2021-08-17 8:43 ` Min Xu
2021-08-17 8:58 ` Gerd Hoffmann
2021-09-11 1:14 ` Erdem Aktas
2021-09-13 6:11 ` [edk2-devel] " Min Xu
2021-08-12 11:56 ` [PATCH 06/23] MdePkg: Add TdxLib to wrap Tdx operations Min Xu
2021-09-11 1:15 ` Erdem Aktas
2021-08-12 11:56 ` [PATCH 07/23] MdePkg: Update BaseIoLibIntrinsicSev to support Tdx Min Xu
2021-08-17 8:38 ` [edk2-devel] " Gerd Hoffmann
2021-08-18 5:54 ` Min Xu
2021-08-19 6:30 ` Gerd Hoffmann
2021-08-19 13:12 ` Min Xu
2021-08-20 6:41 ` Gerd Hoffmann
2021-09-11 1:15 ` Erdem Aktas
2021-09-28 8:33 ` [edk2-devel] " Min Xu
2021-08-12 11:56 ` [PATCH 08/23] UefiCpuPkg: Support TDX in BaseXApicX2ApicLib Min Xu
2021-08-12 11:56 ` [PATCH 09/23] UefiCpuPkg: Add VmTdExitLibNull Min Xu
2021-08-12 11:56 ` [PATCH 10/23] OvmfPkg: Prepare OvmfPkg to use the VmTdExitLib library Min Xu
2021-08-12 11:56 ` [PATCH 11/23] OvmfPkg: Implement library support for VmTdExitLib in Ovmf Min Xu
2021-08-12 11:56 ` [PATCH 12/23] UefiCpuPkg/CpuExceptionHandler: Add base support for the #VE exception Min Xu
2021-08-12 11:56 ` [PATCH 13/23] UefiCpuPkg: Enable Tdx support in MpInitLib Min Xu
2021-08-12 11:56 ` [PATCH 14/23] OvmfPkg: Update SecEntry.nasm to support Tdx Min Xu
2021-08-12 11:56 ` [PATCH 15/23] OvmfPkg: Add IntelTdx.h in OvmfPkg/Include/IndustryStandard Min Xu
2021-08-12 11:56 ` [PATCH 16/23] OvmfPkg: Add TdxMailboxLib Min Xu
2021-08-12 11:56 ` [PATCH 17/23] MdePkg: Add EFI_RESOURCE_ATTRIBUTE_ENCRYPTED in PiHob.h Min Xu
2021-08-12 11:56 ` [PATCH 18/23] OvmfPkg: Enable Tdx in SecMain.c Min Xu
2021-08-19 6:49 ` [edk2-devel] " Gerd Hoffmann
2021-08-19 14:27 ` Min Xu
2021-08-20 7:22 ` Gerd Hoffmann
2021-08-24 12:07 ` Min Xu
2021-08-24 12:55 ` Ard Biesheuvel
2021-08-25 6:10 ` Yao, Jiewen
2021-08-25 7:52 ` Gerd Hoffmann
2021-08-25 9:07 ` Yao, Jiewen
2021-08-25 14:51 ` Gerd Hoffmann
2021-08-25 16:28 ` Yao, Jiewen [this message]
2021-08-26 8:31 ` Gerd Hoffmann
2021-08-26 16:58 ` Yao, Jiewen
2021-08-25 6:22 ` Gerd Hoffmann
2021-08-12 11:56 ` [PATCH 19/23] OvmfPkg: Check Tdx in QemuFwCfgPei to avoid DMA operation Min Xu
2021-08-12 11:56 ` [PATCH 20/23] MdePkg: Add AllocatePagesWithMemoryType support in PeiMemoryAllocationLib Min Xu
2021-08-12 20:43 ` Michael D Kinney
2021-08-15 2:51 ` Min Xu
2021-08-12 11:57 ` [PATCH 21/23] OvmfPkg: Add PcdUse1GPageTable support for TDX Min Xu
2021-08-12 11:57 ` [PATCH 22/23] MdeModulePkg: EFER should not be changed in TDX Min Xu
2021-08-12 11:57 ` [PATCH 23/23] OvmfPkg: Update PlatformPei to support TDX Min Xu
2021-08-31 10:45 ` [edk2-devel] [PATCH 00/23] Enable Intel TDX in OvmfPkg (SEC/PEI) Gerd Hoffmann
2021-09-01 5:41 ` Min Xu
2021-09-01 6:25 ` Gerd Hoffmann
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=PH0PR11MB48851A2EEA36A1CBCE3E31E58CC69@PH0PR11MB4885.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