From patchwork Thu Nov 16 22:45:16 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 10062165 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2CB6C6023A for ; Thu, 16 Nov 2017 22:48:02 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1D87B2AC41 for ; Thu, 16 Nov 2017 22:48:02 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 110532AC43; Thu, 16 Nov 2017 22:48:02 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 669BA2AC41 for ; Thu, 16 Nov 2017 22:48:01 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFSuR-0005Ld-37; Thu, 16 Nov 2017 22:45:23 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFSuP-0005LX-UU for xen-devel@lists.xen.org; Thu, 16 Nov 2017 22:45:22 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id B1/D3-20902-1051E0A5; Thu, 16 Nov 2017 22:45:21 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRWlGSWpSXmKPExsXitHSDvS6DKF+ UwZI+PYslHxezODB6HN39mymAMYo1My8pvyKBNWPxjyXsBXMFKu5/ucDewHiHp4uRk0NCwF9i xYtDbCA2m4C+xO4Xn5hAbBEBdYnTHRdZuxi5OJgFpjBK7L6wGsjh4BAWSJZoehkGUsMioCpxp H8xI4jNK+Ap8WfiWSaImXIS54//ZAaxhQTUJK71X2KHqBGUODnzCQuIzSwgIXHwxQvmCYzcs5 CkZiFJLWBkWsWoUZxaVJZapGtooZdUlJmeUZKbmJmja2hgqpebWlycmJ6ak5hUrJecn7uJERg MDECwg7Fpu+chRkkOJiVR3oijvFFCfEn5KZUZicUZ8UWlOanFhxhlODiUJHgnC/NFCQkWpaan VqRl5gDDEiYtwcGjJMK7FiTNW1yQmFucmQ6ROsVozPFs5usGZo5pV1ubmIVY8vLzUqXEedeBl AqAlGaU5sENgsXLJUZZKWFeRqDThHgKUotyM0tQ5V8xinMwKgnzbgeZwpOZVwK37xXQKUxAp9 jc4AY5pSQRISXVwCjFfaV6wxS5eVL7/aSkVG8GfV+4oE9f7MhEx/Vf0n5vFRT00PuT8vvHpWf PTzL5bXfQclpnqHHM4djt4w/++DB2pm6wu7ile2//u7O/Ra6V350526df5XRM2b8lX5xq+nUq Sh9f0TvFFqCfJGDEdHqzZ+Nirs7srRNKWG4Wpf/0tj5feGOuwQ4lluKMREMt5qLiRADgL6Fqk gIAAA== X-Env-Sender: prvs=486f94740=Andrew.Cooper3@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1510872319!79127832!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 50376 invoked from network); 16 Nov 2017 22:45:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 16 Nov 2017 22:45:20 -0000 X-IronPort-AV: E=Sophos;i="5.44,405,1505779200"; d="scan'208";a="459724731" From: Andrew Cooper To: Xen-devel Date: Thu, 16 Nov 2017 22:45:16 +0000 Message-ID: <1510872316-13762-1-git-send-email-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Cc: Andrew Cooper , Julien Grall , Wei Liu , Jan Beulich Subject: [Xen-devel] [PATCH for-4.10] x86/hvm: Don't corrupt the HVM context stream when writing the MSR record X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Ever since it was introduced in c/s bd1f0b45ff, hvm_save_cpu_msrs() has had a bug whereby it corrupts the HVM context stream if some, but fewer than the maximum number of MSRs are written. _hvm_init_entry() creates an hvm_save_descriptor with length for msr_count_max, but in the case that we write fewer than max, h->cur only moves forward by the amount of space used, causing the subsequent hvm_save_descriptor to be written within the bounds of the previous one. To resolve this, reduce the length reported by the descriptor to match the actual number of bytes used. A typical failure on the destination side looks like: (XEN) HVM4 restore: CPU_MSR 0 (XEN) HVM4.0 restore: not enough data left to read 56 MSR bytes (XEN) HVM4 restore: failed to load entry 20/0 Signed-off-by: Andrew Cooper Reviewed-by: Wei Liu Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Wei Liu CC: Julien Grall This wants backporting to all stable trees, so should also be considered for inclusion into 4.10 at this point. --- xen/arch/x86/hvm/hvm.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 0af498a..c5e8467 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -1330,6 +1330,7 @@ static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h) for_each_vcpu ( d, v ) { + struct hvm_save_descriptor *d = _p(&h->data[h->cur]); struct hvm_msr *ctxt; unsigned int i; @@ -1348,8 +1349,13 @@ static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h) ctxt->msr[i]._rsvd = 0; if ( ctxt->count ) + { + /* Rewrite length to indicate how much space we actually used. */ + d->length = HVM_CPU_MSR_SIZE(ctxt->count); h->cur += HVM_CPU_MSR_SIZE(ctxt->count); + } else + /* or rewind and remove the descriptor from the stream. */ h->cur -= sizeof(struct hvm_save_descriptor); }