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=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 D2E5BC4338F for ; Wed, 18 Aug 2021 21:42:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B0CA7610FF for ; Wed, 18 Aug 2021 21:42:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234069AbhHRVnF (ORCPT ); Wed, 18 Aug 2021 17:43:05 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38966 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233971AbhHRVnE (ORCPT ); Wed, 18 Aug 2021 17:43:04 -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 17ILXQv3127870; Wed, 18 Aug 2021 17:42: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=X/ZVamOOUM56zqGVXqXhKtm9nuRDiqFsLspvE+SmSLo=; b=Fvj1hqL2lX7upR5AKfgOxrK5khFyoj7tgvK5eayO5RO/p+KTsWI4b6x4NesYPKNm3N+A URI+oGD7GOKl59wIxAqQlDVaDpjg2aAcHe+JBVkAhElx+1p0Ulv4XckKKPu8kpwu3W95 1nDtBvZFb9ut851FY4wAOxancWRI6DH2yfhnN2Dxec+YgHDSavkSCbKJF1U3KMphzUKq m6NWsRLWUUwJ+1Dret7m4WmnRasCZX7mUQKIL6KhJ6s15++/dkbNYeJ9WD36XpXAGNyb KFOcnaO5VEq9ygvgefhMfuO8Mq5MtTreEM/4HZK/qicBCanJnaj+yHfcvNkxXBO4tpUP Dg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3agcf6uq2f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Aug 2021 17:42:21 -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 17ILXXVR128249; Wed, 18 Aug 2021 17:42:20 -0400 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 3agcf6uq1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Aug 2021 17:42:20 -0400 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 17ILaRXd000505; Wed, 18 Aug 2021 21:42:19 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma02wdc.us.ibm.com with ESMTP id 3ae5fe5nwm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Aug 2021 21:42:19 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 17ILgHhn8389206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Aug 2021 21:42:18 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3E6CAE07D; Wed, 18 Aug 2021 21:42:17 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 76D89AE06D; Wed, 18 Aug 2021 21:42:17 +0000 (GMT) Received: from Tobins-MacBook-Pro-2.local (unknown [9.77.128.89]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 18 Aug 2021 21:42:17 +0000 (GMT) Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM. To: "Dr. David Alan Gilbert" Cc: Steve Rutherford , Paolo Bonzini , Ashish Kalra , thomas.lendacky@amd.com, brijesh.singh@amd.com, ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com, tobin@ibm.com, jejb@linux.ibm.com, richard.henderson@linaro.org, qemu-devel@nongnu.org, frankeh@us.ibm.com, dovmurik@linux.vnet.ibm.com References: <0fcfafde-a690-f53a-01fc-542054948bb2@redhat.com> <37796fd1-bbc2-f22c-b786-eb44f4d473b9@linux.ibm.com> <458ba932-5150-8706-3958-caa4cc67c8e3@linux.ibm.com> From: Tobin Feldman-Fitzthum Message-ID: Date: Wed, 18 Aug 2021 17:42:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: O_1Qqnfk-yDoDkmanszpGR48sMJ1efjy X-Proofpoint-GUID: lczFpwtEUJtXdyY0Y1zatQYDEk_mM86E X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-18_07:2021-08-17,2021-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 spamscore=0 mlxscore=0 suspectscore=0 phishscore=0 adultscore=0 priorityscore=1501 bulkscore=0 clxscore=1015 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108180132 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 8/18/21 3:04 PM, Dr. David Alan Gilbert wrote: > * Tobin Feldman-Fitzthum (tobin@linux.ibm.com) wrote: >> On 8/17/21 6:04 PM, Steve Rutherford wrote: >>> Ahh, It sounds like you are looking into sidestepping the existing >>> AMD-SP flows for migration. I assume the idea is to spin up a VM on >>> the target side, and have the two VMs attest to each other. How do the >>> two sides know if the other is legitimate? I take it that the source >>> is directing the LAUNCH flows? >> Yeah we don't use PSP migration flows at all. We don't need to send the MH >> code from the source to the target because the MH lives in firmware, which >> is common between the two. > Are you relying on the target firmware to be *identical* or purely for > it to be *compatible* ? It's normal for a migration to be the result of > wanting to do an upgrade; and that means the destination build of OVMF > might be newer (or older, or ...). > > Dave This is a good point. The migration handler on the source and target must have the same memory footprint or bad things will happen. Using the same firmware on the source and target is an easy way to guarantee this. Since the MH in OVMF is not a contiguous region of memory, but a group of functions scattered around OVMF, it is a bit difficult to guarantee that the memory footprint is the same if the build is different. -Tobin > > >> We start the target like a normal VM rather than >> waiting for an incoming migration. The plan is to treat the target like a >> normal VM for attestation as well. The guest owner will attest the target VM >> just like they would any other VM that is started on their behalf. Secret >> injection can be used to establish a shared key for the source and target. >> >> -Tobin >> >>> --Steve >>> 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=-7.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 AFB14C4338F for ; Wed, 18 Aug 2021 21:43:57 +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 24BF0610FF for ; Wed, 18 Aug 2021 21:43:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 24BF0610FF 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]:48322 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGTLo-0004kF-A6 for qemu-devel@archiver.kernel.org; Wed, 18 Aug 2021 17:43:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGTKP-0002i9-Fc for qemu-devel@nongnu.org; Wed, 18 Aug 2021 17:42:29 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:2570) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGTKN-000745-0O for qemu-devel@nongnu.org; Wed, 18 Aug 2021 17:42:28 -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 17ILXQv3127870; Wed, 18 Aug 2021 17:42: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=X/ZVamOOUM56zqGVXqXhKtm9nuRDiqFsLspvE+SmSLo=; b=Fvj1hqL2lX7upR5AKfgOxrK5khFyoj7tgvK5eayO5RO/p+KTsWI4b6x4NesYPKNm3N+A URI+oGD7GOKl59wIxAqQlDVaDpjg2aAcHe+JBVkAhElx+1p0Ulv4XckKKPu8kpwu3W95 1nDtBvZFb9ut851FY4wAOxancWRI6DH2yfhnN2Dxec+YgHDSavkSCbKJF1U3KMphzUKq m6NWsRLWUUwJ+1Dret7m4WmnRasCZX7mUQKIL6KhJ6s15++/dkbNYeJ9WD36XpXAGNyb KFOcnaO5VEq9ygvgefhMfuO8Mq5MtTreEM/4HZK/qicBCanJnaj+yHfcvNkxXBO4tpUP Dg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3agcf6uq2f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Aug 2021 17:42:21 -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 17ILXXVR128249; Wed, 18 Aug 2021 17:42:20 -0400 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 3agcf6uq1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Aug 2021 17:42:20 -0400 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 17ILaRXd000505; Wed, 18 Aug 2021 21:42:19 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma02wdc.us.ibm.com with ESMTP id 3ae5fe5nwm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Aug 2021 21:42:19 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 17ILgHhn8389206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 18 Aug 2021 21:42:18 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3E6CAE07D; Wed, 18 Aug 2021 21:42:17 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 76D89AE06D; Wed, 18 Aug 2021 21:42:17 +0000 (GMT) Received: from Tobins-MacBook-Pro-2.local (unknown [9.77.128.89]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 18 Aug 2021 21:42:17 +0000 (GMT) Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM. To: "Dr. David Alan Gilbert" References: <0fcfafde-a690-f53a-01fc-542054948bb2@redhat.com> <37796fd1-bbc2-f22c-b786-eb44f4d473b9@linux.ibm.com> <458ba932-5150-8706-3958-caa4cc67c8e3@linux.ibm.com> From: Tobin Feldman-Fitzthum Message-ID: Date: Wed, 18 Aug 2021 17:42:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: O_1Qqnfk-yDoDkmanszpGR48sMJ1efjy X-Proofpoint-GUID: lczFpwtEUJtXdyY0Y1zatQYDEk_mM86E X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-18_07:2021-08-17, 2021-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 spamscore=0 mlxscore=0 suspectscore=0 phishscore=0 adultscore=0 priorityscore=1501 bulkscore=0 clxscore=1015 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108180132 Received-SPF: pass client-ip=148.163.156.1; envelope-from=tobin@linux.ibm.com; helo=mx0a-001b2d01.pphosted.com X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.961, 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: , 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, jejb@linux.ibm.com, tobin@ibm.com, qemu-devel@nongnu.org, frankeh@us.ibm.com, Paolo Bonzini , dovmurik@linux.vnet.ibm.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 8/18/21 3:04 PM, Dr. David Alan Gilbert wrote: > * Tobin Feldman-Fitzthum (tobin@linux.ibm.com) wrote: >> On 8/17/21 6:04 PM, Steve Rutherford wrote: >>> Ahh, It sounds like you are looking into sidestepping the existing >>> AMD-SP flows for migration. I assume the idea is to spin up a VM on >>> the target side, and have the two VMs attest to each other. How do the >>> two sides know if the other is legitimate? I take it that the source >>> is directing the LAUNCH flows? >> Yeah we don't use PSP migration flows at all. We don't need to send the MH >> code from the source to the target because the MH lives in firmware, which >> is common between the two. > Are you relying on the target firmware to be *identical* or purely for > it to be *compatible* ? It's normal for a migration to be the result of > wanting to do an upgrade; and that means the destination build of OVMF > might be newer (or older, or ...). > > Dave This is a good point. The migration handler on the source and target must have the same memory footprint or bad things will happen. Using the same firmware on the source and target is an easy way to guarantee this. Since the MH in OVMF is not a contiguous region of memory, but a group of functions scattered around OVMF, it is a bit difficult to guarantee that the memory footprint is the same if the build is different. -Tobin > > >> We start the target like a normal VM rather than >> waiting for an incoming migration. The plan is to treat the target like a >> normal VM for attestation as well. The guest owner will attest the target VM >> just like they would any other VM that is started on their behalf. Secret >> injection can be used to establish a shared key for the source and target. >> >> -Tobin >> >>> --Steve >>>