From: Sean Christopherson <seanjc@google.com>
To: Mathias Krause <minipli@grsecurity.net>
Cc: kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH v3 3/4] x86/access: Forced emulation support
Date: Mon, 3 Apr 2023 17:04:16 -0700 [thread overview]
Message-ID: <ZCtpgGaRN+B91B3G@google.com> (raw)
In-Reply-To: <20230403105618.41118-4-minipli@grsecurity.net>
On Mon, Apr 03, 2023, Mathias Krause wrote:
> Add support to enforce access tests to be handled by the emulator, if
> supported by KVM. Exclude it from the ac_test_exec() test, though, to
> not slow it down too much.
IMO, the slowdown is nowhere near bad enought to warrant exclusion. On bare metal
without KASAN and other debug gunk, the total runtime with EPT enabled is <6s.
With EPT disabled, it's <8s. In a VM, they times are <16s and <26s respectively.
Those are perfectly reasonable, and forcing emulation actually makes the EPT case,
interesting. And the KASAN/debug builds are so horrendously slow that I think we
should figure out a way to special case those kernels anyways.
If you don't object, I'll include FEP as a regular flag when applying.
One other fun thing the usage from vmx_pf_exception_test_guest(), which runs afoul
of a KVM bug. The VMX #PF test runs the access test as an L2 guest (from KVM's
perspective), i.e. triggers emulation from L2. KVM's emulator is goofy and checks
nested intercepts for PAUSE even on vanilla NOPs. SVM filters out non-PAUSE instructions
on the backend, but VMX does not (VMX doesn't have any logic for PAUSE interception
and just ends up injecting a #UD).
I'll post this as a KVM patch.
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 9ae4044f076f..1e560457bf9a 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7898,6 +7898,21 @@ static int vmx_check_intercept(struct kvm_vcpu *vcpu,
/* FIXME: produce nested vmexit and return X86EMUL_INTERCEPTED. */
break;
+ case x86_intercept_pause:
+ /*
+ * PAUSE is a single-byte NOP with a REPE prefix, i.e. collides
+ * with vanilla NOPs in the emulator. Apply the interception
+ * check only to actual PAUSE instructions. Don't check
+ * PAUSE-loop-exiting, software can't expect a given PAUSE to
+ * exit, i.e. KVM is within its rights to allow L2 to execute
+ * the PAUSE.
+ */
+ if ((info->rep_prefix != REPE_PREFIX) ||
+ !nested_cpu_has2(vmcs12, CPU_BASED_PAUSE_EXITING))
+ return X86EMUL_CONTINUE;
+
+ break;
+
/* TODO: check more intercepts... */
default:
break;
next prev parent reply other threads:[~2023-04-04 0:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 10:56 [kvm-unit-tests PATCH v3 0/4] Tests for CR0.WP=0/1 r/o write access Mathias Krause
2023-04-03 10:56 ` [kvm-unit-tests PATCH v3 1/4] x86: Use existing CR0.WP / CR4.SMEP bit definitions Mathias Krause
2023-04-03 10:56 ` [kvm-unit-tests PATCH v3 2/4] x86/access: CR0.WP toggling write to r/o data test Mathias Krause
2023-04-03 10:56 ` [kvm-unit-tests PATCH v3 3/4] x86/access: Forced emulation support Mathias Krause
2023-04-03 11:28 ` Mathias Krause
2023-04-03 19:06 ` Sean Christopherson
2023-04-03 20:06 ` Mathias Krause
2023-04-04 0:08 ` Sean Christopherson
2023-04-04 0:04 ` Sean Christopherson [this message]
2023-04-04 7:27 ` Mathias Krause
2023-04-04 16:36 ` Sean Christopherson
2023-04-05 8:01 ` Mathias Krause
2023-04-03 10:56 ` [kvm-unit-tests PATCH v3 4/4] x86/access: Try emulation for CR0.WP test as well Mathias Krause
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=ZCtpgGaRN+B91B3G@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=minipli@grsecurity.net \
/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