On 9/24/21 2:39 AM, Yao, Jiewen wrote: > Comment below: > >> -----Original Message----- >> From: Gerd Hoffmann <kra...@redhat.com> >> Sent: Friday, September 24, 2021 12:54 PM >> To: Yao, Jiewen <jiewen....@intel.com> >> Cc: Xu, Min M <min.m...@intel.com>; devel@edk2.groups.io; >> brijesh.si...@amd.com; Ard Biesheuvel <ardb+tianoc...@kernel.org>; Justen, >> Jordan L <jordan.l.jus...@intel.com>; Erdem Aktas <erdemak...@google.com>; >> James Bottomley <j...@linux.ibm.com>; Tom Lendacky >> <thomas.lenda...@amd.com> >> Subject: Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector >> >> On Thu, Sep 23, 2021 at 01:38:52PM +0000, Yao, Jiewen wrote: >>> Good point, Min. >>> >>> If >>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fovmf%2Fblob%2Fsnp-&data=04%7C01%7Cbrijesh.singh%40amd.com%7C5452ded75af34b9c73aa08d97f2e8426%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637680660025337914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3yXoKMmZndyiJkpr2gADbq6KvPLoF1r5sCv32MxK4Ms%3D&reserved=0 >> v8/OvmfPkg/ResetVector/X64/OvmfMetadata.asm is the proposal, then I have >> more comment: >>> Type: OVMF_SECTION_TYPE_CODE, OVMF_SECTION_TYPE_VARS are NOT >> used for SEV. I am not sure why they are there. >> >> tdx needs them (for measurement). It's not a tdx-specific concept, >> possibly sev-snp wants use that too in the future. > That means this is only for TDX. SEV does not need this type. Then this is > TDX specific.
FYI, SEV also measures code or data put by the VMM in the guest memory space. In SEV, qemu calls a routine to encrypt the pflash unit0 -- while handling the callback you can convert the GPA to HVA and thus avoid the section. But having the section available is not going to create any issues with the SEV and in some cases it may be useful. >>> Type: OVMF_SECTION_TYPE_CPUID should be SEV specific. TDX does not need >> CPUID page. >> >> A cpuid page can be used without sev too. > I don't think TDX need this field. This is SEV specific. > You are right that CPUID page is currently SEV specific but nothing stops another VMM to use CPUID page on the non-SEV platform to minimize the number of VM exits. I think once guest kernel gets support for using the CPUID page it may become reality sooner. >>> Type: OVMF_SECTION_TYPE_SEC_MEM also seems for SEV. TDX does not >> need this special memory, such as Page table. It is already covered by code. >> >> These are "needs pre-validation / pre-acceptance" regions. >> TDX surely needs that too. > I don't think TDX need this. The page table should be covered by CODE already. > Page table is data page and are not covered by the CODE section. IIUC, TDX also need to accept memory before the access. There are several data pages (such page table, stack, heap, ...) used in the SEC phase; you have two choice, you either accept them during the SEC phase boot or accept them before the boot. If accepted before the boot then they will be measured so that security is not compromised. For simplicity it seems both SNP and TDX decided to accept those data pages before the boot. The metadata simply provides the description of those pre accepted pages. >>> Type: OVMF_SECTION_TYPE_SNP_SECRETS / >> OVMF_SECTION_TYPE_SNP_SEC_MEM is SEV specific. >> >> Yes. >> >>> The SEV table is totally different with TDX metadata table. >> I can't see a fundamental difference. In both cases the VMM needs >> to know the firmware memory layout for (a) attestation, and (b) >> pre-validating/pre-acceptance of memory, and (c) some >> hardware-specific ranges such as snp secrets page. >> >>> I really cannot see the benefit to merge into one table. >> Keep reset vector small? >> Have common parser structs and code? > I think it is opposite. This proposal makes reset vector larger, if we need > define more structure to satisfy TDX, but it is not needed by SEV. Or Define > something purely for SEV, but not useful for TDX. > I don't treat it as benefit. Instead I think it is big burden. > > >> take care, >> Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#81081): https://edk2.groups.io/g/devel/message/81081 Mute This Topic: https://groups.io/mt/85761661/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
