From: Eric Biggers <ebiggers3@gmail.com>
To: linux-kvm@vger.kernel.org, dvyukov@google.com, karahmed@amazon.de
Cc: x86@kernel.org, linux-kernel@vger.kernel.org
Subject: CONFIG_KCOV causing crash in svm_vcpu_run()
Date: Sun, 13 May 2018 20:00:07 -0700 [thread overview]
Message-ID: <20180514030007.GH677@sol.localdomain> (raw)
With CONFIG_KCOV=y and an AMD processor, running the following program crashes
the kernel with no output (I'm testing in a VM, so it's using nested
virtualization):
#include <fcntl.h>
#include <linux/kvm.h>
#include <sys/ioctl.h>
int main()
{
int dev, vm, cpu;
char page[4096] __attribute__((aligned(4096))) = { 0 };
struct kvm_userspace_memory_region memreg = {
.memory_size = 4096,
.userspace_addr = (unsigned long)page,
};
dev = open("/dev/kvm", O_RDONLY);
vm = ioctl(dev, KVM_CREATE_VM, 0);
cpu = ioctl(vm, KVM_CREATE_VCPU, 0);
ioctl(vm, KVM_SET_USER_MEMORY_REGION, &memreg);
ioctl(cpu, KVM_RUN, 0);
}
It bisects down to commit b2ac58f90540e39 ("KVM/SVM: Allow direct access to
MSR_IA32_SPEC_CTRL"). The bug is apparently that due to the new code for
managing the SPEC_CTRL MSR, __sanitizer_cov_trace_pc() is being called from
svm_vcpu_run() before the host's MSR_GS_BASE has been restored, which causes a
crash somehow. The following patch fixes it, though I don't know that it's the
right solution; maybe KCOV should be disabled in the function instead, or maybe
there's a more fundamental problem. What do people think?
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 1fc05e428aba8..d35ef241e66d8 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -5652,6 +5652,15 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
#endif
);
+#ifdef CONFIG_X86_64
+ wrmsrl(MSR_GS_BASE, svm->host.gs_base);
+#else
+ loadsegment(fs, svm->host.fs);
+#ifndef CONFIG_X86_32_LAZY_GS
+ loadsegment(gs, svm->host.gs);
+#endif
+#endif
+
/*
* We do not use IBRS in the kernel. If this vCPU has used the
* SPEC_CTRL MSR it may have left it on; save the value and
@@ -5676,15 +5685,6 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu)
/* Eliminate branch target predictions from guest mode */
vmexit_fill_RSB();
-#ifdef CONFIG_X86_64
- wrmsrl(MSR_GS_BASE, svm->host.gs_base);
-#else
- loadsegment(fs, svm->host.fs);
-#ifndef CONFIG_X86_32_LAZY_GS
- loadsegment(gs, svm->host.gs);
-#endif
-#endif
-
reload_tss(vcpu);
local_irq_disable();
next reply other threads:[~2018-05-14 2:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-14 3:00 Eric Biggers [this message]
2018-05-14 3:02 ` CONFIG_KCOV causing crash in svm_vcpu_run() Eric Biggers
2018-05-14 5:14 ` Dmitry Vyukov
2018-05-14 17:25 ` Eric Biggers
2018-05-15 5:33 ` Dmitry Vyukov
2019-02-27 7:14 ` Eric Biggers
2019-02-27 8:21 ` Dmitry Vyukov
2018-05-22 21:56 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180514030007.GH677@sol.localdomain \
--to=ebiggers3@gmail.com \
--cc=dvyukov@google.com \
--cc=karahmed@amazon.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kvm@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox