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.web11.8803.1607529308600694578 for ; Wed, 09 Dec 2020 07:55:08 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=PZssAiAs; 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.42/8.16.0.42) with SMTP id 0B9FVYqv128955; Wed, 9 Dec 2020 10:55:03 -0500 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=B3YKkpE1V9WjCr5Wq0/T+Ex7NO/lh8OUn2ggRlyG9WQ=; b=PZssAiAs1SyY2dDHvtEk67NW9ftd/dkXTS/JIZXPXqBAsv2kktOi+VhyCAZ0wsR/RCSS ciY8LVGb6Ys4lKR/KWYUN2tV3o7Qh1NkINUa1QfSuvvIsU1KJ2FOhEQdmXtflzs9MDmb LhLPe/LzRmr5vYQMW4MLkv7fcauAjkMQQ2RWYAQ9sVZ9iZkROEW+VKQFKy1fbsFiIMr6 J89NyAiIfjQo8QqrEZCZK4KSNu5OZmQWApJN1xsfb4ryGVGRWfOgaHrFXp4j2lcBuQF8 e5ADRZKFh+HjpkA8utphbNEyU8riD8McJg4pz4k131kvll0zTD6nc+oauwdADR0Lg1s7 rA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 35b1041aw4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Dec 2020 10:55:03 -0500 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0B9FWFgZ132202; Wed, 9 Dec 2020 10:55:03 -0500 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com with ESMTP id 35b1041avn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Dec 2020 10:55:03 -0500 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0B9Fq6Hv008511; Wed, 9 Dec 2020 15:55:02 GMT Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by ppma01dal.us.ibm.com with ESMTP id 3581u9gr99-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Dec 2020 15:55:02 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0B9Fswa38848052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Dec 2020 15:54:58 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8BD097805C; Wed, 9 Dec 2020 15:54:58 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EF40278060; Wed, 9 Dec 2020 15:54:55 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.183.17]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 9 Dec 2020 15:54:55 +0000 (GMT) Message-ID: <2975e120c1764f9a3f26c0c74a23b1ddc161c4ad.camel@linux.ibm.com> Subject: Re: [edk2-devel] [PATCH v3 6/6] OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: devel@edk2.groups.io, jiewen.yao@intel.com Cc: "dovmurik@linux.vnet.ibm.com" , "Dov.Murik1@il.ibm.com" , "ashish.kalra@amd.com" , "brijesh.singh@amd.com" , "tobin@ibm.com" , "david.kaplan@amd.com" , "jon.grimm@amd.com" , "thomas.lendacky@amd.com" , "frankeh@us.ibm.com" , "Dr . David Alan Gilbert" , Laszlo Ersek , "Justen, Jordan L" , Ard Biesheuvel Date: Wed, 09 Dec 2020 07:54:54 -0800 In-Reply-To: References: <20201130202819.3910-1-jejb@linux.ibm.com> <20201130202819.3910-7-jejb@linux.ibm.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343,18.0.737 definitions=2020-12-09_13:2020-12-09,2020-12-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 phishscore=0 adultscore=0 priorityscore=1501 spamscore=0 suspectscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012090108 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2020-12-09 at 07:46 -0800, James Bottomley wrote: > On Wed, 2020-12-09 at 12:02 +0000, Yao, Jiewen wrote: > > Would you please take a look at intel-tdx-guest-hypervisor- > > communication-interface, section 4.4 storage volume key data. OK, I read through the spec. > > We defined multiple key layout, key type and key format. Please let > > us know if you have any thought. > > I really think the standard GUIDed form: > > GUID|len|data > > Works best because a GUID is big enough to define for any number of > uses and it also means we don't have to define key types or anything, > because all a new consumer has to do is define their data structure > and give it a guid. The single uefi config table is passed through > to all the elements until it gets to one that recognizes the GUID. The only other thing I would add here, is that you have indirect ACPI tables whereas the above is direct. I think indirect might be useful at the low level for scatter gather injection if it has to be done for the architecture, but I think to make it easier for the consumers above OVMF we gather all the information into on GUIDed table with no indirection, which makes the above GUIDed form the best description. James