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.web12.88.1621984544313851549 for ; Tue, 25 May 2021 16:15:44 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=AqxuC8df; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14PN2WZK130248; Tue, 25 May 2021 19:15:39 -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=SGMxnkWIsBzzjeeUAKe6bpKjGuprUH73dc5J/77qFFc=; b=AqxuC8dfFD/Baj5uHM/XsX2AA9GxUuAZAQzSeJ+K4t9lC/XJDOK/YqB09CDLBu1T75pS anThl5LSFpOtqW4t8oyNijUvdyp1UiPOCumdy8ORaTzQLzI8HAtMufJcfReaEc6vOwX7 rEmJN0tOaekqF2uuEPW5ve2DMVh4k7JAi+zp2wX8gweaP5jOcaC/4f/HMOrXeAknkvQF KydR8t9bn6LV2HrkIOJ3llbF6BDC8CKNZs+sEZoNoVtQkFeBp5ARGeOZ6bisGqiUIwMW 5Te0cGeSAp1u2HSfrgF1ERy66gCmbWIJVF+3/DXXBcYrFV0LXOJcE9IAYsglsgq2mUyu mA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 38s7uk4ek0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 19:15:39 -0400 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 14PNCPsH185555; Tue, 25 May 2021 19:15:38 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 38s7uk4ej8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 19:15:38 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 14PN78L7001064; Tue, 25 May 2021 23:15:37 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma01dal.us.ibm.com with ESMTP id 38s1m251s8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 23:15:37 +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 14PNFZqJ35586480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 May 2021 23:15:35 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4C2277805C; Tue, 25 May 2021 23:15:35 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B0DB87805F; Tue, 25 May 2021 23:15:32 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.80.208.94]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Tue, 25 May 2021 23:15:32 +0000 (GMT) Message-ID: Subject: Re: [edk2-devel] [PATCH v1 0/8] Measured SEV boot with kernel/initrd/cmdline From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Tom Lendacky , Dov Murik , devel@edk2.groups.io, brijesh.singh@amd.com Cc: Tobin Feldman-Fitzthum , Tobin Feldman-Fitzthum , Jim Cadden , Hubertus Franke , Laszlo Ersek , Ard Biesheuvel , Jordan Justen , Ashish Kalra , Erdem Aktas , Jiewen Yao , Min Xu Date: Tue, 25 May 2021 16:15:31 -0700 In-Reply-To: References: <20210525053116.1533673-1-dovmurik@linux.ibm.com> <8b966d52-f207-b747-96a7-2ed6f29aa432@amd.com> <21593112-ea9c-8cd1-7cad-6fc6d9645242@linux.ibm.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 0d-JSky42EqsZ2UOiVgh6liyx97kC02X X-Proofpoint-GUID: Q3CQlG1shgBuid6FTTFsG-VNz9s9B7_7 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-05-25_09:2021-05-25,2021-05-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 suspectscore=0 spamscore=0 malwarescore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105250142 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2021-05-25 at 15:33 -0500, Tom Lendacky wrote: > On 5/25/21 3:08 PM, Dov Murik wrote: > > Hi Brijesh, > > > > On 25/05/2021 18:48, Brijesh Singh wrote: > > > On 5/25/21 12:31 AM, Dov Murik wrote: > > > > Booting with SEV prevented the loading of kernel, initrd, and > > > > kernel command-line via QEMU fw_cfg interface because they > > > > arrive from the VMM which is untrusted in SEV. > > > > > > > > However, in some cases the kernel, initrd, and cmdline are not > > > > secret but should not be modified by the host. In such a case, > > > > we want to verify inside the trusted VM that the kernel, > > > > initrd, and cmdline are indeed the ones expected by the Guest > > > > Owner, and only if that is the case go on and boot them up > > > > (removing the need for grub inside OVMF in that mode). > > > > > > > > This patch series declares a new page in MEMFD which will > > > > contain the hashes of these three blobs (kernel, initrd, > > > > cmdline), each under its own GUID entry. This tables of hashes > > > > is populated by QEMU before launch, and encrypted as part of > > > > the initial VM memory; this makes sure theses hashes are part > > > > of the SEV measurement (which has to be approved by the Guest > > > > Owner for secret injection, for example). Note that this > > > > requires a new QEMU patch which will be submitted soon. > > > > > > I have not looked at the patches, but trying to brainstorm if we > > > can avoid reserving a new page in the MEMFD and use the existing > > > EDK2 infrastructure to verify the blobs (kernel, initrd) loaded > > > through the FW_CFG interface in the guest memory. > > > > > > If I understand correctly, then in your proposed approach, guest > > > owner wants to ensure that the hypevisor passing its preferred > > > kernel, initrd and cmdline. The guest owner basically knows the > > > hashes of these components in advance. > > > > Yes, that's correct. > > > > > So, can we do something like this: > > > > > > - The secret blob provided by the guest owner should contains the > > > hashes (sha384) of these components. > > > > > > - Use openssl API available in the edk2 to calculate the hash > > > while loading the kernel, initrd and cmdline. > > > > Indeed we do something similar already - we use Sha256HashAll (see > > patch 5 in this series). > > > > > > > - Before booting the kernel, compare the calculated hash with the > > > one listed in the secret page. If they don't match then fail > > > otherwise continue. > > > > That is indeed what we do in patch 6 (the calls to our > > ValidateHashEntry). > > > > > > > Did I miss something ? > > > > Thanks for proposing this. > > > > Your approach has the advantage that there's no need for extra > > pre-allocated MEMFD page for the hashes, and also it makes the QEMU > > flow simpler (QEMU doesn't need to compute the hashes and put them > > in that special MEMFD page). I think that the only change we'll > > need from QEMU in the x86_load_linux flow (which is when the user > > supplies -kernel/-initrd) is that it won't modify any memory in a > > way that the modifies the hashes that Guest Owner expects (for > > example, avoid writing over the kernel's setup area). > > > > However, the disadvantage is that it unifies boot measurement with > > the secret injection. The Guest Owner _must_ inject the hashes, > > otherwise the system doesn't boot; whereas in our current > > suggestion the Guest Owner can check the measurement, verify that > > everything is OK, and just let the guest continue. > > > > But as I write this, I think that maybe without secret injection > > the guest is not really secure? Because the host could just > > continue execution of the guest without waiting for measurement > > check... If the Guest Owner _must_ inject a secret for SEV to be > > secure in any case, we might as well choose your path and let the > > Guest Owner inject the table of hashes themselves. > > > > I'd like to hear your (and others') thoughts. > > Brijesh and I had a long discussion over this. I think that if you're > dealing with a malicious hypervisor, then it could, in fact, measure > all the components that it wants to be used and, using > LAUNCH_UPDATE_DATA, add a page, that matches the format of the guest > secret page, to the guest and indicate that page as the guest secret. > Even though the measurement would fail validation by the guest owner, > the hypervisor could ignore it and continue to run the guest. > > So you need something that proves ownership of the guest secret - > like a disk key that would fail to unlock the disk if the hypervisor > is faking the guest secret. > > Does all that make sense? I think it does for the unencrypted boot case. For the encrypted boot case, the HV can't inject the decryption key, because it doesn't know it, so the interior guest will know there's a problem as soon as it can't decrypt the image. But I get the point that we can't rely on the secrets page for hashes if we have nothing cryptographic in it. However, the actual threat from this is somewhat unclear. As you note: the guest owner knows there's a problem, but the actual guest is still executing because of intervention by a malicious hypervisor owner. In the cloud that's more or less equivalent to me taking over the guest IP and trying to man in the middle the services ... once the guest owner knows this happened, they're going to be looking for a new CSP. So I think the threat would be potent if you could convince the guest owner that nothing were amiss, so they think the modified guest is legitimate, but less so otherwise. James