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.web09.20636.1604965455712059700 for ; Mon, 09 Nov 2020 15:44:15 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="no key for verify" header.i=@ibm.com header.s=pp1 header.b=YOcuNfMP; spf=temperror, err=temporary DNS error (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0A9NVqDo001813; Mon, 9 Nov 2020 18:44:13 -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=g9rg6gY6u0LTmhWOaWhu2i7t79Rr10JPMghNUTnWA3Q=; b=YOcuNfMP3F3w3pgWT5zj8ywqduokE+wN1P7MOqTCG6So8u3MTmod42srTR/2kLF5wa20 d0Hbk70H+Zjh0bXRQdmRdufao9+/wnLsp0x0qZ+Sz5Ex1OWVOUwlTLMAdw93uCTweyUW 75DArpitSdj7hrVVIYHB0X+dYje0Am7iBySCdYWObjBxGQIDklE1Xq9JAlFdzLHRX+/S KhHk7yTDPk530Rpxm0ER/mZvdqxzKbhX9D6GceDKvUBF0GVclEekwUuwfVDVcVIzT5Kx kLJNPj0x04UjO6257U/rOWD+OUjtUF1HrKKmuHzaaIbcwUhU18T57KFX8/sRW7bja1WY ug== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 34qc6ent8h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Nov 2020 18:44:13 -0500 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 0A9NZJL0017414; Mon, 9 Nov 2020 18:44:13 -0500 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 34qc6ent8b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Nov 2020 18:44:13 -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 0A9Ne2t9018106; Mon, 9 Nov 2020 23:44:12 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 34nk7a19rj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Nov 2020 23:44:12 +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 0A9Ni2lB21561634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Nov 2020 23:44:02 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 23C8078060; Mon, 9 Nov 2020 23:44:08 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CA99F7805F; Mon, 9 Nov 2020 23:44:05 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.85.162.106]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 9 Nov 2020 23:44:05 +0000 (GMT) Message-ID: Subject: Re: [edk2-devel] RFC: Fast Migration for SEV and SEV-ES - blueprint and proof of concept From: James Bottomley Reply-To: jejb@linux.ibm.com To: devel@edk2.groups.io, tobin@linux.ibm.com, dgilbert@redhat.com Cc: Laszlo Ersek , 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 Date: Mon, 09 Nov 2020 15:44:04 -0800 In-Reply-To: References: <933a5d2b-a495-37b9-fe8b-243f9bae24d5@redhat.com> <61acbc7b318b2c099a106151116f25ea@linux.vnet.ibm.com> <20201106163848.GM3576@work-vm> <6c4d7b90a59d3df6895d8c0e35f7a2cd@linux.vnet.ibm.com> <20201109195620.GS3024@work-vm> 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.312,18.0.737 definitions=2020-11-09_14:2020-11-05,2020-11-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1011 bulkscore=0 spamscore=0 adultscore=0 impostorscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011090145 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2020-11-09 at 17:37 -0500, Tobin Feldman-Fitzthum wrote: > On 2020-11-09 14:56, Dr. David Alan Gilbert wrote: > > * Tobin Feldman-Fitzthum (tobin@linux.ibm.com) wrote: [...] > > > We're still working out some of the details in QEMU, but the > > > basic idea of transferring memory is that each time the HV needs > > > to send a page to the target, it will ask the Migration Handler > > > in the guest for a version of the page that is encrypted with a > > > transport key. Since the MH is inside the guest, it can read > > > from any address in guest memory. The Migration Handlers on the > > > source and the target will share a key. Once the source encrypts > > > the requested page with the transport key, it can safely hand it > > > off to the HV. Once the page reaches the target, the target HV > > > will pass the page into the Migration Handler, which will decrypt > > > using the transport key and move the page to the appropriate > > > address. > > > > So somehow we have to get that transport key negotiated and into > > the the migration-handlers. > > Inject-launch-secret is one of the main pieces here. James might have > more info about this step. So there are a couple of ways I was thinking this could work. In the current slow migration, the PSPs on each end validate each other by exchanging keys. We could do something similar by having the two MHs do an ECDHE exchange to agree a trusted transfer key between them and then having them both exchange trusted information about the SEV environment i.e. both validating each other. However, the alternative and simpler way is simply to have the machine owner control everything. So encrypted boot would provision two secrets: one for the actual encrypted root which grub needs but the other would be what the MH needs. The MH secret would be the private part of an ECDH key (effectively the MH identity) and the public ECDH key of the MH source, so only the source MH would be able to make encrypted contact for migration. On boot from image, the public key part would be empty indicating boot should proceed normally. On migration, we make sure we know the source public key and provision it to the target along with a random target key. To trigger the migration, we have to tell the source what the target's public key is and they can now make encrypted contact in a manner that should be cryptographically secure. The MH ECDH key would exist for the lifetime of the VM on a SEV system and would be destroyed on either image shutdown or successful migration. James