From patchwork Fri Feb 5 07:37:57 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jan Beulich X-Patchwork-Id: 8232541 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 58A349F37A for ; Fri, 5 Feb 2016 07:40:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6484820395 for ; Fri, 5 Feb 2016 07:40:34 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6C01220383 for ; Fri, 5 Feb 2016 07:40:33 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aRaxt-0005vl-Qp; Fri, 05 Feb 2016 07:38:01 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aRaxs-0005ve-Ii for xen-devel@lists.xenproject.org; Fri, 05 Feb 2016 07:38:00 +0000 Received: from [85.158.143.35] by server-2.bemta-4.messagelabs.com id 3D/5E-08977-75154B65; Fri, 05 Feb 2016 07:37:59 +0000 X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-10.tower-21.messagelabs.com!1454657877!14124112!1 X-Originating-IP: [137.65.248.74] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11136 invoked from network); 5 Feb 2016 07:37:58 -0000 Received: from prv-mh.provo.novell.com (HELO prv-mh.provo.novell.com) (137.65.248.74) by server-10.tower-21.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 5 Feb 2016 07:37:58 -0000 Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Fri, 05 Feb 2016 00:37:56 -0700 Message-Id: <56B45F6502000078000CED8B@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Fri, 05 Feb 2016 00:37:57 -0700 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Cc: George Dunlap , Andrew Cooper , Christoph Egger , Keir Fraser Subject: [Xen-devel] [PATCH] x86/nHVM: avoid NULL deref during INVLPG intercept handling X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When intercepting (or emulating) L1 guest INVLPG, the nested P2M pointer may be (is?) NULL, and hence there's no point in calling p2m_flush(). In fact doing so would cause a dereference of that NULL pointer at least in the ASSERT() right at the beginning of the function. While so far nothing supports hap_invlpg() being reachable from the INVLPG intercept paths (only INVLPG insn emulation would lead there), and hence the code in question (added by dd6de3ab99 ["Implement Nested-on-Nested"]) appears to be dead, this seems to be the change which can be agreed on as an immediate fix. Ideally, however, the problematic code would go away altogether. See thread at lists.xenproject.org/archives/html/xen-devel/2016-01/msg03762.html. Reported-by: 刘令 Signed-off-by: Jan Beulich x86/nHVM: avoid NULL deref during INVLPG intercept handling When intercepting (or emulating) L1 guest INVLPG, the nested P2M pointer may be (is?) NULL, and hence there's no point in calling p2m_flush(). In fact doing so would cause a dereference of that NULL pointer at least in the ASSERT() right at the beginning of the function. While so far nothing supports hap_invlpg() being reachable from the INVLPG intercept paths (only INVLPG insn emulation would lead there), and hence the code in question (added by dd6de3ab99 ["Implement Nested-on-Nested"]) appears to be dead, this seems to be the change which can be agreed on as an immediate fix. Ideally, however, the problematic code would go away altogether. See thread at lists.xenproject.org/archives/html/xen-devel/2016-01/msg03762.html. Reported-by: ?? Signed-off-by: Jan Beulich --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -687,7 +687,8 @@ static bool_t hap_invlpg(struct vcpu *v, * Must perform the flush right now or an other vcpu may * use it when we use the next VMRUN emulation, otherwise. */ - p2m_flush(v, vcpu_nestedhvm(v).nv_p2m); + if ( vcpu_nestedhvm(v).nv_p2m ) + p2m_flush(v, vcpu_nestedhvm(v).nv_p2m); return 1; } Reviewed-by: Andrew Cooper Acked-by: George Dunlap --- a/xen/arch/x86/mm/hap/hap.c +++ b/xen/arch/x86/mm/hap/hap.c @@ -687,7 +687,8 @@ static bool_t hap_invlpg(struct vcpu *v, * Must perform the flush right now or an other vcpu may * use it when we use the next VMRUN emulation, otherwise. */ - p2m_flush(v, vcpu_nestedhvm(v).nv_p2m); + if ( vcpu_nestedhvm(v).nv_p2m ) + p2m_flush(v, vcpu_nestedhvm(v).nv_p2m); return 1; }