From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web08.21261.1630930617302725484 for ; Mon, 06 Sep 2021 05:16:57 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FwPpGe2B; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630930616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ynZc4Og33YEWCak86Djrk9v/2Nd6/feMJ80fZrhpSA0=; b=FwPpGe2BUUjJG0rX1hTAjJ5uBs68kAg4Ec9Yp2TGx6m2dvX1eIEWRI0LqU1W9EviRLjySe JdHjveydf7x0YqpgGIOO5O7qvPw1kN7S6U8Bsx3IZRfHZtUMZJVUIDvL2Nw6J2IE4PZZZx sO+DB3bjyfiKz4wAZzVgi/eAxSOUNgQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-152-hTeEHNfPNH22b8GNJ-3nOg-1; Mon, 06 Sep 2021 08:16:54 -0400 X-MC-Unique: hTeEHNfPNH22b8GNJ-3nOg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9F21D107ACC7; Mon, 6 Sep 2021 12:16:52 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4646B60BF4; Mon, 6 Sep 2021 12:16:52 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A413E18007A6; Mon, 6 Sep 2021 14:16:50 +0200 (CEST) Date: Mon, 6 Sep 2021 14:16:50 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , Brijesh Singh , James Bottomley , "Yao, Jiewen" , Tom Lendacky , "Justen, Jordan L" , Ard Biesheuvel , Erdem Aktas , Michael Roth Subject: Re: [edk2-devel] [PATCH v6 06/29] OvmfPkg/ResetVector: pre-validate the data pages used in SEC phase Message-ID: <20210906121650.vwgt5y5hdwxfugvh@sirius.home.kraxel.org> References: <20210901161646.24763-1-brijesh.singh@amd.com> <20210901161646.24763-7-brijesh.singh@amd.com> <20210902082029.tfdt4s5s76qknpiq@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > > sevSnpBootBlockStart: > > > + DD SNP_HV_VALIDATED_START > > > + DD SNP_HV_VALIDATED_END > We pack all the Tdx information into a blob (TdxMetadata). These tdx information > Includes the BFV(i.e. OVMF_CODE.fd), the CFV(i.e. OVMF_VARS.fd), TdMailbox, etc. > The offset to the TdxMetadata is in the GUIDed chain in ResetVectorVtf0.asm. > In the future new metadata can be added into the TdxMetadata without changes > in ResetVectorVtf0.asm. [ Looking at https://www.mail-archive.com/devel@edk2.groups.io/msg33605.html ] So, there isn't much tdx-specific in tdx-metadata. Most ranges are TDX_METADATA_SECTION_TYPE_TEMP_MEM which I think basically means these ranges should be accepted by the hypervisor, which is pretty much the same issue snp tries to solve with this pre-validation range. Then there are the ranges for code (aka bfv), for vars (aka cfv) and td_hob. td_hob is the only tdx-specific item there, and even that concept (pass memory ranges as hob list from hypervisor to guest) might be useful outside tdx. So, can we settle on one approach for this please? I think the tdx-metadata style approach is more flexible and future-proof. It can easily be extended without changing data structures, we only need new section types. I expect this will work better long-term when it comes to backward-compatibility. I'd suggest we generalize the tdx-metadata idea and define both generic and vmm-specific section types: enum { OVMF_SECTION_TYPE_UNDEFINED = 0; /* generic */ OVMF_SECTION_TYPE_CODE = 0x100, OVMF_SECTION_TYPE_VARS OVMF_SECTION_TYPE_SEC_MEM /* vmm should accept/validate this */ /* sev */ OVMF_SECTION_TYPE_SEV_SECRETS = 0x200, OVMF_SECTION_TYPE_SEV_CPUID /* or move to generic? */ /* tdx */ OVMV_SECTION_TYPE_TDX_TD_HOB = 0x300, }; Comments? Looking at tdx-metadata I have a few questions: +_Bfv: + DD TDX_BFV_RAW_DATA_OFFSET + DD TDX_BFV_RAW_DATA_SIZE What is this and why is it needed? + DQ TDX_BFV_MEMORY_BASE + DQ TDX_BFV_MEMORY_SIZE Why "DQ"? TDX is defined to start in 32bit mode, so you can hardly have addresses here which do not fit into "DD", correct? + DD TDX_METADATA_SECTION_TYPE_BFV + DD TDX_METADATA_ATTRIBUTES_EXTENDMR What does this attribute mean? take care, Gerd