From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web08.954.1623168079625101327 for ; Tue, 08 Jun 2021 09:01:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=ZqhxTKeq; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 158FY1PV176679; Tue, 8 Jun 2021 12:01:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : reply-to : to : cc : date : in-reply-to : references : content-type : content-transfer-encoding : mime-version; s=pp1; bh=VnrLYyEQwLkFS6fjYRzw/q/SAV+VREYS7jyWtd4ZWtA=; b=ZqhxTKeqGRkpfZtqKoS+ioljKtkOK7Fj4x/vUN7q0OGmyjXE2rku9pilGREP011uSamK tMp74GMEnPvUeSwliQXZSgCLHpftwYGy6NHL7pr3Zef5Rf0YjDRZdL3zougewyz1njmP G5wIK4fVQdJsnhYKxiCzVz7z2BfPdhyO5LDINi/VmnOC2qC4j7jr4i8xA3hblm6ODE/O p3/9U8LFbXnNFIFNl2ii/GE/Q/yVedxesfU94td0+7ZQa0VF46R2jYqCSM4qYc5qFlZd NB6kYnX8tXeDeXHqCVo2Z/vrncGl4JlYuDYmoE4PBmW/FwMk+mt1FMJJvVzQP5RBA17p dA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 39266dur9w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jun 2021 12:01:12 -0400 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 158FYR2g181485; Tue, 8 Jun 2021 12:01:12 -0400 Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0b-001b2d01.pphosted.com with ESMTP id 39266dur8v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jun 2021 12:01:12 -0400 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 158FxY7B029532; Tue, 8 Jun 2021 16:01:10 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma02dal.us.ibm.com with ESMTP id 3900wapmx6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jun 2021 16:01:10 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 158G19Do35783084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 8 Jun 2021 16:01:09 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6210F7807E; Tue, 8 Jun 2021 16:01:09 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3E43D7805C; Tue, 8 Jun 2021 16:01:06 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.129.99]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 8 Jun 2021 16:01:05 +0000 (GMT) Message-ID: Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: "Yao, Jiewen" , "rfc@edk2.groups.io" , "devel@edk2.groups.io" Cc: Laszlo Ersek , Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." Date: Tue, 08 Jun 2021 09:01:04 -0700 In-Reply-To: References: User-Agent: Evolution 3.34.4 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: u4LFrF1Y2izearVzso31FVyGAsjhJNLs X-Proofpoint-ORIG-GUID: UvPPA5ODITc6aZxwA4qelWivOVR952io X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-06-08_10:2021-06-04,2021-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 phishscore=0 impostorscore=0 suspectscore=0 bulkscore=0 priorityscore=1501 mlxlogscore=948 clxscore=1015 mlxscore=0 spamscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106080099 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2021-06-03 at 13:51 +0000, Yao, Jiewen wrote: > Hi, All > We plan to do a design review for TDVF in OVMF package. > > > The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11) > is now available in blow link: > https://edk2.groups.io/g/devel/files/Designs/2021/0611. > > The Bugzilla is https://bugzilla.tianocore.org/show_bug.cgi?id=3429 It looks like I'll be travelling that day, but should be able to attend at least the first 45 minutes of the design review from the airport lounge. > You can have an offline review first. You comments will be warmly > welcomed and we will continuously update the slides based on the > feedbacks. On TdMailbox and TdHob, we already have two SEV pages in the MEMFD and since TDX and SEV is an either/or, could we simply not rename both pages and use them for either boot depending on what CPU type is detected, so we only have two MEMFD pages, not four? On your slide 13 Question: "Open: How will the QEMU find the metadata location?" can't you just use the mechanism for SEV that's already upstream in both QEMU and OVMF? On slide 19, the mucking with the reset vector really worries me because we don't have that much space to play with. Given that you're starting in 32 bit mode and can thus enter anywhere in the lower 4GB, why not simply use a different and TDX specific entry point? I'm not quite sure why you don't have a PEI phase, since TdxStartupLib seems effectively to be PEI. On all the Tcg2 changes: what about installing a vTPM driver that simply translates to your MSRs? That way we can use all the standard TCG code as is? Plus then we could do SEV-SNP measurement through an actual vTPM running at higher VMPL or something. Slide 41: IOMMU operation. The implication is that you only transition to unencrypted memory for DMA during the actual operation, so do I have it correct that the guest writes DMA to encrypted memory, then the iommu marks the region as unencrypted and transforms the memory to be in the clear and then transforms it back after the DMA operation completes? Given that SEV operates quite happily with always in the clear DMA buffers, this seems to have the potential to be a performance problem, but what security does it gain? James