Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3516441ybz; Mon, 27 Apr 2020 17:31:45 -0700 (PDT) X-Google-Smtp-Source: APiQypK6nYbO8yqHCdjB3nc2JIoR4rEemzBFqcZFlxkc3a5mjMDIGoTPN4lXf45f+jLiz3EAvJP+ X-Received: by 2002:a17:906:b2c4:: with SMTP id cf4mr23108973ejb.340.1588033905723; Mon, 27 Apr 2020 17:31:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588033905; cv=none; d=google.com; s=arc-20160816; b=LE3amNJUagKlfpr6evDXIgfDX+SSr9o+1e5YnXXtLCah4BvAN8fBzLB9eerbJ3xKM3 Lt4cXn1X4xDt2XhWluSCvU5ft/iBls1VMo9QdX8KzYKdleZzBj5H1jxIfJ0H2VYWscN8 sufLzOxzXvUDgzOzu561sjmLOw16RO4Q2lQe/rfSlhdHl+oslPmQTfPdY3bxUTmLGKRE GXHNqrltaUcs7xM5wzRscM+J8HG2F/+X0RYwjCOUvg8Ed2nlTQ8H0fFT6IKSdH79q2fs l3jlwevJcnu28xAdDQA1uXZS+G73m14OFFy5rtRCLaoLV5chhfBm11KtVaowqIkQgYYo iq7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=8Z3XKyHxAG7IUAvzD9JfBuXDfdRYbv9qqPO6eeYSrFk=; b=tCREMWgva1r9LjlJXdUmsHHakENr1KYbTjdx7nzHWDvjhcmtzsUZgGr9AmzsJR1jm/ 3No8tK0t07UENDKdMf4e8LFSJvTcrnmczxNUYolsQ15iLffhxqKqCGp7zYBSZklsUQlm iCw2L4JcbundeAb3PwXocoi+Nzk399PoTzv1wjhnbKKjAnb+5loTgb2LWW3lWJsmdLEg 7392dO8SEP9C9rq1bGDpclFBFVT13dmNRNpVdmtXmV9LTxvmFYNKEzLjUvQbp+nj1UlC HZd/YWgPMiFuFnzq/vn/j7+Ypy4CJYdbA54xFhd3yWiBkLCqYGVcsajhC1bdvPpEXes4 HtBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="ORd7/HnR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bd6si31832edb.277.2020.04.27.17.31.20; Mon, 27 Apr 2020 17:31:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="ORd7/HnR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726379AbgD1A3H (ORCPT + 99 others); Mon, 27 Apr 2020 20:29:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726016AbgD1A3G (ORCPT ); Mon, 27 Apr 2020 20:29:06 -0400 Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 90918C0610D5 for ; Mon, 27 Apr 2020 17:29:06 -0700 (PDT) Received: by mail-il1-x142.google.com with SMTP id i16so18600959ils.12 for ; Mon, 27 Apr 2020 17:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Z3XKyHxAG7IUAvzD9JfBuXDfdRYbv9qqPO6eeYSrFk=; b=ORd7/HnRA28Oya0GJjq9fEZBcHElM84CebAGT4i17uPekgJx2dJnHcDe0AwBvb+NwJ BvxTMdG5eJHN2Arut0iXak3+TVVQqJZNkMADD5eTou0O/biFl0+XHSQu6YchIsvOdfPQ Qa6vAx0Zx4tx9ZNlgdiSSCrcDooIBRmJTN/4T7cwnMmBIT6c5uzfXDjkwAu3GXtFrFXc 7/121vdRAmQ/izha0afgQbXyNncGbFsL79Zvd6Ncxp7hzKli0XC3Vv5abDouCS49QWDy tBwlGrb3lEgcEy4V8pJ9Q8s8kw1ox5zPvbzuTaA3xItOcGLUu42+DqABWJNOboJG3iNH glVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Z3XKyHxAG7IUAvzD9JfBuXDfdRYbv9qqPO6eeYSrFk=; b=CEz99Cc0FJQ1r3Ej7WguxL2qvnBUv1jbcFOaERqp3W7OjGTsalz0GmwULnCbxv+Q2r V2xl1qvOdoOfo9S/FevH+nMRpCYrwmzXXxbMJpUJviqfDomC+uCcldpm4R0Gjfl/CL5+ YAGLIMHo4+K/6LT5f+3YF+Su4N7roCgFEr/8COlJ12DzNBlEvHTF2IWRwXOkSBcRPQUH ez+V610EG2Lyk1MHvx2FqwQnMjQ1ZIQfef5ls1NV6hhT6ckDbo8L2D0rOnomAO3t9hK9 2HpgoZ5eMQh//tsh534mPFyfEGre3WYEXmHgXVyUgR6ZXKynjXMl5yQYpndXNnEEorEk 5bfw== X-Gm-Message-State: AGi0PuYf+YTT73nOKCJaqojxTZOyDgaL0KfVc/m+KTwiDt/yWahLxBrb 6brx+NYJSaDHF0oXZH/+vmAXPF9OJsvagGY+JPBKeQ== X-Received: by 2002:a92:d8ca:: with SMTP id l10mr23867156ilo.118.1588033745597; Mon, 27 Apr 2020 17:29:05 -0700 (PDT) MIME-Version: 1.0 References: <20200427165917.31799-1-pbonzini@redhat.com> In-Reply-To: <20200427165917.31799-1-pbonzini@redhat.com> From: Jim Mattson Date: Mon, 27 Apr 2020 17:28:54 -0700 Message-ID: Subject: Re: [PATCH] KVM: x86: handle wrap around 32-bit address space To: Paolo Bonzini Cc: LKML , kvm list , Sean Christopherson , Joerg Roedel , everdox@gmail.com 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 On Mon, Apr 27, 2020 at 9:59 AM Paolo Bonzini wrote: > > KVM is not handling the case where EIP wraps around the 32-bit address > space (that is, outside long mode). This is needed both in vmx.c > and in emulate.c. SVM with NRIPS is okay, but it can still print > an error to dmesg due to integer overflow. > > Reported-by: Nick Peterson > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/emulate.c | 2 ++ > arch/x86/kvm/svm/svm.c | 3 --- > arch/x86/kvm/vmx/vmx.c | 15 ++++++++++++--- > 3 files changed, 14 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > index bddaba9c68dd..de5476f8683e 100644 > --- a/arch/x86/kvm/emulate.c > +++ b/arch/x86/kvm/emulate.c > @@ -5798,6 +5798,8 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt) > } > > ctxt->eip = ctxt->_eip; > + if (ctxt->mode != X86EMUL_MODE_PROT64) > + ctxt->eip = (u32)ctxt->_eip; > > done: > if (rc == X86EMUL_PROPAGATE_FAULT) { > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 8f8fc65bfa3e..d5e72b22bc87 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -319,9 +319,6 @@ static int skip_emulated_instruction(struct kvm_vcpu *vcpu) > if (!kvm_emulate_instruction(vcpu, EMULTYPE_SKIP)) > return 0; > } else { > - if (svm->next_rip - kvm_rip_read(vcpu) > MAX_INST_SIZE) > - pr_err("%s: ip 0x%lx next 0x%llx\n", > - __func__, kvm_rip_read(vcpu), svm->next_rip); > kvm_rip_write(vcpu, svm->next_rip); > } > svm_set_interrupt_shadow(vcpu, 0); > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index 3ab6ca6062ce..ed1ffc8a727b 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -1556,7 +1556,7 @@ static int vmx_rtit_ctl_check(struct kvm_vcpu *vcpu, u64 data) > > static int skip_emulated_instruction(struct kvm_vcpu *vcpu) > { > - unsigned long rip; > + unsigned long rip, orig_rip; > > /* > * Using VMCS.VM_EXIT_INSTRUCTION_LEN on EPT misconfig depends on > @@ -1568,8 +1568,17 @@ static int skip_emulated_instruction(struct kvm_vcpu *vcpu) > */ > if (!static_cpu_has(X86_FEATURE_HYPERVISOR) || > to_vmx(vcpu)->exit_reason != EXIT_REASON_EPT_MISCONFIG) { > - rip = kvm_rip_read(vcpu); > - rip += vmcs_read32(VM_EXIT_INSTRUCTION_LEN); > + orig_rip = kvm_rip_read(vcpu); > + rip = orig_rip + vmcs_read32(VM_EXIT_INSTRUCTION_LEN); > +#ifdef CONFIG_X86_64 > + /* > + * We need to mask out the high 32 bits of RIP if not in 64-bit > + * mode, but just finding out that we are in 64-bit mode is > + * quite expensive. Only do it if there was a carry. > + */ > + if (unlikely(((rip ^ orig_rip) >> 31) == 3) && !is_64_bit_mode(vcpu)) Is it actually possible to wrap around 0 without getting a segment limit violation, or is it only possible to wrap *to* 0 (i.e. rip==1ull << 32)? > + rip = (u32)rip; > +#endif > kvm_rip_write(vcpu, rip); > } else { > if (!kvm_emulate_instruction(vcpu, EMULTYPE_SKIP)) > -- > 2.18.2 >