Received: by 10.213.65.68 with SMTP id h4csp907988imn; Tue, 27 Mar 2018 10:59:55 -0700 (PDT) X-Google-Smtp-Source: AIpwx49adQpF5H2H33zkP61OtqDAAq3Z34t1GZltM0Ne6Gd46abtdmTRqdNoc5TmZidJiAHdyU06 X-Received: by 2002:a17:902:8492:: with SMTP id c18-v6mr324522plo.40.1522173595038; Tue, 27 Mar 2018 10:59:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522173595; cv=none; d=google.com; s=arc-20160816; b=QSY+U6QsMsdz2/Xi/T9X3CbJQlFsM8ohGNNzCZKIMZkX3l5iP4QdQSyPrBZ1M718Wm XxJa95HfN2aH3WZvN0pj63D8CC9alE5V7MnRzy4v1tth9ybV+CunqetHQ0KjWkrD/GoA Pb8q3ELARQas1dn5/Dct1ZTknuDp2KIOA975q0sz1oln8ws0uxc9BXrtOgtz1QV5RLbE iyCYtdMUzqDSjk406R6d2Z79xEhtwJ4atA+fJMxmI9Mb7qpjIMSRsWmrgOtktB/2bBJr iUtcZv/ksKXMO7/cNbq2c6XfZkSKWCJZ1B8Qu0v54uyQcbc8wLiKfQQ6Vo9aJ9iaEYNV UIyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=J0RvS+0FGyXzWB3Wyv032ZQMjZt1shmwY9GmKxNcHls=; b=T58qwptqEBIUR7kpk5+Jn+WBW1k7cQzshRv5Wct8+qzFA/JJhqQ1V+wJWs1NIG8YJd T1cBaM5wzraW4Lat1T1eNLuGDxlcNrdjYDoTq2UMuQn2GiCqonDj4pctizNj9VLczuZu k6Xay4yPKBeLChNSBm/clz+KM0n9LAUwrJ0ObENZ8vHt95Cgh+jZVajf6hCnKkKcOM8u t/dr5oFEgmH/ZW+JlLXt825dxVQ7Vb4TnJdZXYchy16VOcRyoHOhLmto80o2+kVhOuAA TcalW7U2FTetj2i+RFkiqeCnFM2Kk4fmTMoXy6TLk9ieVNhuEYo6nxxgviAr6/8VInYj OdTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j91-v6si1632718pld.14.2018.03.27.10.59.40; Tue, 27 Mar 2018 10:59:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753147AbeC0Qal (ORCPT + 99 others); Tue, 27 Mar 2018 12:30:41 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:42072 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753068AbeC0Qai (ORCPT ); Tue, 27 Mar 2018 12:30:38 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id C879A11B6; Tue, 27 Mar 2018 16:30:37 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andy Lutomirski , Paolo Bonzini , Linus Torvalds Subject: [PATCH 4.4 35/43] kvm/x86: fix icebp instruction handling Date: Tue, 27 Mar 2018 18:27:39 +0200 Message-Id: <20180327162718.377784713@linuxfoundation.org> X-Mailer: git-send-email 2.16.3 In-Reply-To: <20180327162716.407986916@linuxfoundation.org> References: <20180327162716.407986916@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Linus Torvalds commit 32d43cd391bacb5f0814c2624399a5dad3501d09 upstream. The undocumented 'icebp' instruction (aka 'int1') works pretty much like 'int3' in the absense of in-circuit probing equipment (except, obviously, that it raises #DB instead of raising #BP), and is used by some validation test-suites as such. But Andy Lutomirski noticed that his test suite acted differently in kvm than on bare hardware. The reason is that kvm used an inexact test for the icebp instruction: it just assumed that an all-zero VM exit qualification value meant that the VM exit was due to icebp. That is not unlike the guess that do_debug() does for the actual exception handling case, but it's purely a heuristic, not an absolute rule. do_debug() does it because it wants to ascribe _some_ reasons to the #DB that happened, and an empty %dr6 value means that 'icebp' is the most likely casue and we have no better information. But kvm can just do it right, because unlike the do_debug() case, kvm actually sees the real reason for the #DB in the VM-exit interruption information field. So instead of relying on an inexact heuristic, just use the actual VM exit information that says "it was 'icebp'". Right now the 'icebp' instruction isn't technically documented by Intel, but that will hopefully change. The special "privileged software exception" information _is_ actually mentioned in the Intel SDM, even though the cause of it isn't enumerated. Reported-by: Andy Lutomirski Tested-by: Paolo Bonzini Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- arch/x86/include/asm/vmx.h | 1 + arch/x86/kvm/vmx.c | 9 ++++++++- 2 files changed, 9 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/vmx.h +++ b/arch/x86/include/asm/vmx.h @@ -310,6 +310,7 @@ enum vmcs_field { #define INTR_TYPE_NMI_INTR (2 << 8) /* NMI */ #define INTR_TYPE_HARD_EXCEPTION (3 << 8) /* processor exception */ #define INTR_TYPE_SOFT_INTR (4 << 8) /* software interrupt */ +#define INTR_TYPE_PRIV_SW_EXCEPTION (5 << 8) /* ICE breakpoint - undocumented */ #define INTR_TYPE_SOFT_EXCEPTION (6 << 8) /* software exception */ /* GUEST_INTERRUPTIBILITY_INFO flags. */ --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -1011,6 +1011,13 @@ static inline bool is_machine_check(u32 (INTR_TYPE_HARD_EXCEPTION | MC_VECTOR | INTR_INFO_VALID_MASK); } +/* Undocumented: icebp/int1 */ +static inline bool is_icebp(u32 intr_info) +{ + return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK)) + == (INTR_TYPE_PRIV_SW_EXCEPTION | INTR_INFO_VALID_MASK); +} + static inline bool cpu_has_vmx_msr_bitmap(void) { return vmcs_config.cpu_based_exec_ctrl & CPU_BASED_USE_MSR_BITMAPS; @@ -5333,7 +5340,7 @@ static int handle_exception(struct kvm_v (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))) { vcpu->arch.dr6 &= ~15; vcpu->arch.dr6 |= dr6 | DR6_RTM; - if (!(dr6 & ~DR6_RESERVED)) /* icebp */ + if (is_icebp(intr_info)) skip_emulated_instruction(vcpu); kvm_queue_exception(vcpu, DB_VECTOR);