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.3286.1621973299634011887 for ; Tue, 25 May 2021 13:08:19 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=i35FnZZU; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: dovmurik@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 14PK3KDJ102882; Tue, 25 May 2021 16:08:17 -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=Q/Z7By7fvbh+ruLp0SzwG3La8OQY2hHQKg/s0yZl7oE=; b=i35FnZZUaVYN/M02wK9u/rJMrSZ8UoE8nW1rMmXQtTNGHKos6BAaz38aofBeCy4lwLTm Wm+3lyYkSawlwl8R89JIRN61aeALzfW6csqgc2oberYyDgSfTd2I8Pg66Ah5IoeDP209 OXOxUmglXBUF0LArYycEirvOfDDLqV4xxQY5PR1pAPH7wnFidd7dAay1L+kK06kZtm+C 3ehtlOfVHtX+yG5lmNoMc2IN+08H38C6sxzGMlKotJYsvI6hgs51I/MHrNvdRkmg/3Ac 1VYEt+KPl++gwF3s56lHJaToHn6MTtdoxDyR2/kNInryY5WYDjLzRrGmOIwNz55csz1q Tg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 38s5w3utfm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 16:08:17 -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 14PK59T8112179; Tue, 25 May 2021 16:08:16 -0400 Received: from ppma04ams.nl.ibm.com (63.31.33a9.ip4.static.sl-reverse.com [169.51.49.99]) by mx0a-001b2d01.pphosted.com with ESMTP id 38s5w3uteg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 16:08:16 -0400 Received: from pps.filterd (ppma04ams.nl.ibm.com [127.0.0.1]) by ppma04ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 14PK3NM1011767; Tue, 25 May 2021 20:08:14 GMT Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by ppma04ams.nl.ibm.com with ESMTP id 38s1r485w1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 May 2021 20:08:14 +0000 Received: from d06av24.portsmouth.uk.ibm.com (d06av24.portsmouth.uk.ibm.com [9.149.105.60]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 14PK8BGo27984208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 May 2021 20:08:11 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7D6294204B; Tue, 25 May 2021 20:08:11 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 23CEE42045; Tue, 25 May 2021 20:08:07 +0000 (GMT) Received: from [9.65.213.35] (unknown [9.65.213.35]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 25 May 2021 20:08:06 +0000 (GMT) Subject: Re: [edk2-devel] [PATCH v1 0/8] Measured SEV boot with kernel/initrd/cmdline To: devel@edk2.groups.io, brijesh.singh@amd.com 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 References: <20210525053116.1533673-1-dovmurik@linux.ibm.com> <8b966d52-f207-b747-96a7-2ed6f29aa432@amd.com> From: "Dov Murik" Message-ID: <21593112-ea9c-8cd1-7cad-6fc6d9645242@linux.ibm.com> Date: Tue, 25 May 2021 23:08:05 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <8b966d52-f207-b747-96a7-2ed6f29aa432@amd.com> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: wUSfwk0dCJ1-u3lmLreM72nwbLhTDV3g X-Proofpoint-GUID: 0ECpljBUZhR2k1k1R37NTN9QwmjLwQsZ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.761 definitions=2021-05-25_08:2021-05-25,2021-05-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 spamscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1015 impostorscore=0 phishscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105250123 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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. -Dov