From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx.groups.io with SMTP id smtpd.web11.33384.1618238041509112462 for ; Mon, 12 Apr 2021 07:34:01 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=PKdrkZPJ; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13CEXD8G116336; Mon, 12 Apr 2021 10:33:59 -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 : mime-version : content-transfer-encoding; s=pp1; bh=yXASGj4sH/p9FS4ByDPWFUcoWXn2JDeuDo7WzU2wZyQ=; b=PKdrkZPJMUBZD8D8A9d4txCfz6kScxsu/lOgXCcXhx0KGOWkih2TMMhQbg0Mt4WQQXT6 s3OP6VX/oWMmzvfUahIvKtqOKQX4JQLwI3QdR3LfuuWcptDF877vJe1FAwDI+1/n0p7u lzK4Jkpa4AkHxXvXGreoNhfaAmLH6aPmW/JKLkTFKLDp9/PHuGvW8nf5OMkQkHi/bs3T 2jsJOL2ZprKOs0QRp4lNOkAqg/TX+aMWMxC9ZzB/XUTyxJtDVsD4v+eaxGPdyOXh0TS8 gqqkuA4HBe271xsZ1BiPrjH3xt0nZXerHneI7NLfK2EhMFsV5DjOFg/UoyWy8SVgbbPl dA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 37urymexex-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Apr 2021 10:33:59 -0400 Received: from m0098394.ppops.net (m0098394.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 13CEXHN4116782; Mon, 12 Apr 2021 10:33:58 -0400 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com with ESMTP id 37urymexea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Apr 2021 10:33:58 -0400 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 13CES2iZ010861; Mon, 12 Apr 2021 14:33:57 GMT Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by ppma04dal.us.ibm.com with ESMTP id 37u3n8myy0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Apr 2021 14:33:57 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 13CEXuw514745954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Apr 2021 14:33:56 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6189A78064; Mon, 12 Apr 2021 14:33:56 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AE34C7805E; Mon, 12 Apr 2021 14:33:53 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.203.222]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 12 Apr 2021 14:33:53 +0000 (GMT) Message-ID: Subject: Re: [edk2-devel] separate OVMF binary for TDX? [was: OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest] From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: "Yao, Jiewen" , "devel@edk2.groups.io" , "dgilbert@redhat.com" , Laszlo Ersek Cc: "Xu, Min M" , "thomas.lendacky@amd.com" , Brijesh Singh , "Justen, Jordan L" , Ard Biesheuvel , Paolo Bonzini , Nathaniel McCallum Date: Mon, 12 Apr 2021 07:33:52 -0700 In-Reply-To: References: <719a63e555376ca65a7bbe0c7e23c20b6b631cd3.camel@linux.ibm.com> <9aa00ba0-def0-9a4e-1578-0b55b8047ebd@redhat.com> <2ff2c569-1032-3e5f-132a-159c47c9f067@amd.com> <18180548-016d-4e37-68fd-050dfc3b4e77@redhat.com> <5183d5fd-9bba-6f0a-52e0-a3e27a6784de@redhat.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: rTeeeg42vD-4LXEv1Dcree3gZba23Qij X-Proofpoint-ORIG-GUID: UnJH2HydvTqaUkcu-DVMAALHLc_SNLoP X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-04-12_10:2021-04-12,2021-04-12 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 clxscore=1015 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104120096 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2021-04-12 at 11:54 +0000, Yao, Jiewen wrote: > I totally agree with you that from security perspective, the best > idea to isolate AMD SEV/Intel TDX from standard OVMF. There's a big difference between building tuned binaries and separating the subsystems entirely. Ideally we don't want customers running images to have to build them differently for Intel or AMD (a bit like how QEMU/KVM hide the VM differences from users), and Confidential Computing shares a huge amount of interface similarity, so we wouldn't want that separated. I think the rule should be that if both Intel and AMD expose a feature in different ways, OVMF tries to expose a uniform API for that feature over two differing implementations. > Do you want to propose move AMD SEV support to another SEC? You mean have an entirely separate SEC for AMD, OVMF and Intel? I really wouldn't do that: much that's in the SEC: page table setup, memory mapping and decompression is common to all of them. This all follows for a lot of the components. To build separate binaries, we just need separate dsc and fdf files. Then I think the goal would be to share as much as possible to avoid duplicating the maintenance and possibly diverging the user API. James