From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F2A5C4338F for ; Thu, 19 Aug 2021 22:11:29 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7CA096109E for ; Thu, 19 Aug 2021 22:11:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7CA096109E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:35450 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGqFz-00069u-7d for qemu-devel@archiver.kernel.org; Thu, 19 Aug 2021 18:11:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGqF9-0005PV-Un for qemu-devel@nongnu.org; Thu, 19 Aug 2021 18:10:35 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40388) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGqF8-0004bA-5L for qemu-devel@nongnu.org; Thu, 19 Aug 2021 18:10:35 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17JM3UMq073374; Thu, 19 Aug 2021 18:10:29 -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=s9oQOAi1oMeLWbk2SGSqnGs5buytPLYhHtKMOaBIb6A=; b=aM14whoIUSVhsMuqIdU5/2qLydGj9CPyPAK8w6xAZDsQ5OaRDPa4wMqll3fcLI2UJiQu 64WyMSA3LGRpcWrurZbKkPMJNT8wb2tzl2ldhFOgIJRAiTBh6/n33Re5HAKYPyxz6Osx XeHG2HdHkZwiMmNpCJeqMg5J29fIEiBNw9MamP5NQoETjSQLxk3UGrjVT4zhpoDKAGHJ GCSxHEPtr4VksPfcTOjwMjNEWEPqPG/4+yHTvOuy9qqGeFcnpGb7QpXAZ55MaI0VqhZc RWOWYDzYTRmvhYDw0zaD3K6YwvjdSV3hKwBbaN33lZWJsmTXxnLUeecL7f3vuGP9nsjq Bg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3ahk0yr6j4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 18:10:29 -0400 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 17JM5UAk086447; Thu, 19 Aug 2021 18:10:28 -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 3ahk0yr6hu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 18:10:28 -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 17JM3T03021949; Thu, 19 Aug 2021 22:10:27 GMT Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by ppma01dal.us.ibm.com with ESMTP id 3ahu0ta8yy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 22:10:27 +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 17JMAPCL34865546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Aug 2021 22:10:25 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7474878063; Thu, 19 Aug 2021 22:10:25 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A97567805E; Thu, 19 Aug 2021 22:10:22 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.160.128.138]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 19 Aug 2021 22:10:22 +0000 (GMT) Message-ID: Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM. From: James Bottomley To: "Dr. David Alan Gilbert" Date: Thu, 19 Aug 2021 15:10:21 -0700 In-Reply-To: References: <0fcfafde-a690-f53a-01fc-542054948bb2@redhat.com> <37796fd1-bbc2-f22c-b786-eb44f4d473b9@linux.ibm.com> <458ba932-5150-8706-3958-caa4cc67c8e3@linux.ibm.com> <538733190532643cc19b6e30f0eda4dd1bc2a767.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: KeEQZ4f5mgVctXjPAxt3LZpPoLy6mHZn X-Proofpoint-ORIG-GUID: 22mbp_qpwaXsEiVgdQPm2zFx57CDAg1s X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-19_07:2021-08-17, 2021-08-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 phishscore=0 impostorscore=0 suspectscore=0 clxscore=1015 malwarescore=0 adultscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108190126 Received-SPF: pass client-ip=148.163.156.1; envelope-from=jejb@linux.ibm.com; helo=mx0a-001b2d01.pphosted.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: jejb@linux.ibm.com Cc: thomas.lendacky@amd.com, Ashish Kalra , brijesh.singh@amd.com, ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, Steve Rutherford , richard.henderson@linaro.org, tobin@ibm.com, qemu-devel@nongnu.org, frankeh@us.ibm.com, Tobin Feldman-Fitzthum , Paolo Bonzini , dovmurik@linux.vnet.ibm.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 2021-08-19 at 15:28 +0100, Dr. David Alan Gilbert wrote: > * James Bottomley (jejb@linux.ibm.com) wrote: > > On Thu, 2021-08-19 at 09:22 +0100, Dr. David Alan Gilbert wrote: [...] > > > I think it really does have to cope with migration to a new > > > version of host. > > > > Well, you're thinking of OVMF as belonging to the host because of > > the way it is supplied, but think about the way it works in > > practice now, forgetting about confidential computing: OVMF is RAM > > resident in ordinary guests, so when you migrate them, the whole of > > OVMF (or at least what's left at runtime) goes with the migration, > > thus it's not possible to change the guest OVMF by migration. The > > above is really just an extension of that principle, the only > > difference for confidential computing being you have to have an > > image of the current OVMF ROM in the target to seed migration. > > > > Technically, the problem is we can't overwrite running code and > > once the guest is re-sited to the target, the OVMF there has to > > match exactly what was on the source for the RT to still > > function. Once the migration has run, the OVMF on the target must > > be identical to what was on the source (including internally > > allocated OVMF memory), and if we can't copy the MH code, we have > > to rely on the target image providing this identical code and we > > copy the rest. > > I'm OK with the OVMF now being part of the guest image, and having to > exist on both; it's a bit delicate though unless we have a way to > check it (is there an attest of the destination happening here?) There will be in the final version. The attestations of the source and target, being the hash of the OVMF (with the registers in the -ES case), should be the same (modulo any firmware updates to the PSP, whose firmware version is also hashed) to guarantee the OVMF is the same on both sides. We'll definitely take an action to get QEMU to verify this ... made a lot easier now we have signed attestations ... James