From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web08.30924.1627311028721578232 for ; Mon, 26 Jul 2021 07:50:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=EVFfSFyU; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16QEi5Pr194711; Mon, 26 Jul 2021 10:50:23 -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=RyDk8UWvypWFG8lahV68pMALy5o2+lVSX34N4cdgrkE=; b=EVFfSFyUbDYGU5TMGk01TxbwISP85BUEkqhUQXRBj57QYtyT5zgSElzWjJpTz3XBsUiZ zFC7ad9x4kWTXRN1wJEmXFs5a1/TfGom2zQq+rNmSiA/l7MpZExjadKJjCYyMswgKa4z tIVvLGHhzJCJUgIReKsjeSg1fXm6kOu7evJJpjsciOENlvgF335+fqyas1Vtk/pamVlp 4XTBxox5qQJXrq7cd5r0omMGXa6nkV58c/ssfw/zxb+YiJ0IP5gl/d4UGGCJtWLFLKVQ dLE2PKYa+pciYEmlC1LiHa/5OyPFt0+6orETbY1vAJyQ6lC/JnbtFF13JAGi4MH7ZSfW ug== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3a1y2n85ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Jul 2021 10:50:23 -0400 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 16QEje4V007095; Mon, 26 Jul 2021 10:50:23 -0400 Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0a-001b2d01.pphosted.com with ESMTP id 3a1y2n85by-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Jul 2021 10:50:22 -0400 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 16QEmlAb030391; Mon, 26 Jul 2021 14:50:22 GMT Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by ppma01wdc.us.ibm.com with ESMTP id 3a0agajh60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Jul 2021 14:50:22 +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 16QEoKfg25493948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Jul 2021 14:50:20 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E2C8578068; Mon, 26 Jul 2021 14:50:19 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7B80278079; Mon, 26 Jul 2021 14:50:11 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.129.14]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 26 Jul 2021 14:50:11 +0000 (GMT) Message-ID: Subject: Re: [edk2-devel] [PATCH v4 00/11] Measured SEV boot with kernel/initrd/cmdline From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: "Yao, Jiewen" , "devel@edk2.groups.io" , "dovmurik@linux.ibm.com" Cc: Tobin Feldman-Fitzthum , Tobin Feldman-Fitzthum , Jim Cadden , Hubertus Franke , Ard Biesheuvel , "Justen, Jordan L" , Ashish Kalra , Brijesh Singh , Erdem Aktas , "Xu, Min M" , Tom Lendacky , Leif Lindholm , Sami Mujawar Date: Mon, 26 Jul 2021 07:50:10 -0700 In-Reply-To: References: <20210722084307.2890952-1-dovmurik@linux.ibm.com> <711c0ad9-9ebe-0eaa-e04b-28e7e7f69ef4@linux.ibm.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: r2IirNdHMH4kba_58Rfpbm_j5dsWpg-F X-Proofpoint-ORIG-GUID: nyNLMtFExBiqZVD-7niTCLx1M0y64sv- X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-07-26_06:2021-07-26,2021-07-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 malwarescore=0 phishscore=0 adultscore=0 spamscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107260082 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2021-07-26 at 00:55 +0000, Yao, Jiewen wrote: > Hi James > "However, this ran into problems when it was decided AmdSev shouldn't > have it's own Library." > > I am not clear on the history. Would you please clarify why AmdSev > should not have its own library? The history predates me. It was already done for the Bhyve package which also has a modified PlatformBootManagerLib when I came along with this. However, only having Library in the top level package seems to be a common edk2 pattern if you run a find. > It looks not reasonable to me. AmdSev is just a feature. A feature > may have its own library. We have enough examples. We do? Running find . -name Library -print only turns up ./FmpDevicePkg/Test/UnitTest/Library As not following the top level package only pattern. > Also, the instance name "Grub" is very confusing. I compared > PlatformBootManagerLib and PlatformBootManagerLibGrub. This is just a > customized PlatformBootManagerLib. It's called Grub because it places Grub in the Fv for combined pre- attestation. Either SEV or TDX could use this (Although TDX looks likely not to want to). > For example, XEN feature removing and PIIX4 difference has nothing to > do with Grub... > ================= > PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x60), 0x0b); // A > PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x61), 0x0b); // B > PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x62), 0x0a); // C > PciWrite8 (PCI_LIB_ADDRESS (0, 1, 0, 0x63), 0x0a); // D > ================= It's part of the boot path stripping to make sure there's a hard failure if Grub fails to execute. There's a Bugzilla requiring more of this because a grub only booting platform library needs fewer extraneous things which could constitute an attack surface for the injected secret. > It is a big misleading. Can we move the PlatformBootManagerLibGrub To > AmdSev now? I think you probably want to ask around older edk2 package maintainers and see if there's any reason for this pattern, which seems to be strongly enforced. If no-one can remember, then likely it can be broken. James