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.web10.467.1626724463128606220 for ; Mon, 19 Jul 2021 12:54:23 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@ibm.com header.s=pp1 header.b=ar5C+8b5; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: dovmurik@linux.ibm.com) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16JJiSUB187961; Mon, 19 Jul 2021 15:54:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=4c235MPH/Caz5RgvTPajMltkTDR7xXcViwOhsBdmveA=; b=ar5C+8b51tadQBi/5/YzBpzxkT/NmC1em/GSbKAARWF4IhxtPvXSHy2updvgRPEHQXGp 8KiY8mqux9ro38Ylw6g6DfNAYYbsQgB1XSrynrFa8BwcDPdY7jo/oOP5VPr509MhHhqG 243GDVDtfYmrh6gDmKu9D54gJAKGNpi7Q/phOMaSUXJx4gUToITHomjZh98HIztXbmAi tfvn11fwCRT72FKwcf30zqeYB3UHFCYzLApoRyF76JKiDrSV0e+F6iW1v0m/IZa6E9B+ TrZ7TZZrgKs1qKOsn4oD521CnzMUMnB+72dHrvlFKyjnR2dKTQHzzr1MhsgkHPXrW0NW Tw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 39wegnanvp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jul 2021 15:54:20 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 16JJkvX0195099; Mon, 19 Jul 2021 15:54:20 -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 39wegnanup-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jul 2021 15:54:20 -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 16JJchZI007723; Mon, 19 Jul 2021 19:54:19 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma01wdc.us.ibm.com with ESMTP id 39upub2qv0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jul 2021 19:54:19 +0000 Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 16JJsHlO25624866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Jul 2021 19:54:17 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 82A87124073; Mon, 19 Jul 2021 19:54:17 +0000 (GMT) Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7C5A2124085; Mon, 19 Jul 2021 19:54:14 +0000 (GMT) Received: from [9.65.195.237] (unknown [9.65.195.237]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTP; Mon, 19 Jul 2021 19:54:14 +0000 (GMT) Subject: Re: [PATCH v2 07/11] OvmfPkg/QemuKernelLoaderFsDxe: call VerifyBlob after fetch from fw_cfg To: Brijesh Singh , devel@edk2.groups.io Cc: Tobin Feldman-Fitzthum , Tobin Feldman-Fitzthum , Jim Cadden , James Bottomley , Hubertus Franke , Laszlo Ersek , Ard Biesheuvel , Jordan Justen , Ashish Kalra , Erdem Aktas , Jiewen Yao , Min Xu , Tom Lendacky , Dov Murik References: <20210706085501.1260662-1-dovmurik@linux.ibm.com> <20210706085501.1260662-8-dovmurik@linux.ibm.com> <02974eb3-d919-f147-10f8-605ca7c152cb@amd.com> <440f919c-7360-936c-ecbf-ead7b06e9ea4@amd.com> From: "Dov Murik" Message-ID: Date: Mon, 19 Jul 2021 22:54:13 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <440f919c-7360-936c-ecbf-ead7b06e9ea4@amd.com> X-TM-AS-GCONF: 00 X-Proofpoint-GUID: weVYkhi9t3dmGq5VeyCeExti36_RE2U1 X-Proofpoint-ORIG-GUID: X4GTDCLzkdao5gActZU-rNfp069stFCw X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-07-19_09:2021-07-19,2021-07-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 spamscore=0 clxscore=1015 priorityscore=1501 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107190111 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-001b2d01.pphosted.com id 16JJiSUB187961 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 19/07/2021 18:19, Brijesh Singh wrote: >=20 >=20 > On 7/19/21 7:22 AM, Dov Murik wrote: >>> The patch itself is okay. Just curious, do we also need to add a >>> verification for the QEMU FW cfg file ? >>> >> >> I don't really understand.=C2=A0 This patch adds the VerifyBlob() call= on >> blobs that were read by FetchBlob(), which in turn reads the contents = of >> kernel/initrd/cmdline from QEMU FW cfg (using QemuFwCfgReadBytes for >> example). >> >> We currently *don't* add verification for all other FW cfg settings, >> like number of CPUs, E820 memory entries, ... similar to what we (don'= t) >> do in SEV boot with encrypted root image (in which only OVMF is >> measured). >> >> What else do you think we should verify? >> >=20 > As I understand that your series is attempting to add more security > checks in the SEV boot sequence; i.e. after this series is merged, we > can verify the kernel,cmdline and initrd passed through qemu. But there > are several other configuration parameters (such as e820, acpi) that > gets passed by the qemu and consumed by the ovmf. Are you considering t= o > add the checks to cover those blobs in the future series? To me it seem= s > that the framework built here can be extended to cover those as well. >=20 You're right -- it can be extended. Currently that's not the plan; the Guest Owner should be able to verify the measurement, which, with this patch series, is a combination of the OVMF, kernel, initrd, and cmdline. Adding the other QEMU FW CFG values will make that even harder for the Guest Owner. Also, the measurement will be different if, for example, the guest is launched with 8GB memory instead of 4GB, or with 8 vcpus instead of 4 vcpus. If there's an obvious attack possible via one of those fw_cfg settings, we can think how to extend the measurement to cover the problematic settings (or not support them at all, if possible). > Reviewed-by: Brijesh Singh >=20 Thanks! -Dov