Re: [kvm-unit-tests PATCH v3 3/4] x86/access: Forced emulation support

[Mathias Krause <minipli@grsecurity.net>]

On 04.04.23 02:04, Sean Christopherson wrote:
> 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.

You must have a more beefy machine than I do. Testing bare metal on a
NUC12 (i7-1260P) with kvm.ko loaded with force_emulation_prefix=1 and
not excluding AC_FEP_BIT from ac_test_bump() gives me a runtime of
little over 41s with EPT enabled and, funnily, only 9s with EPT
disabled, as that implicitly excludes the CR4.PKE tests, reducing the
number of tests to run by a factor of 10 (~38 million tests down do 3.8
million). The non-EPT run took 56s in a VM but the EPT one ran into the
90s timeout. After lifting that, it was 2m22s. :/

For comparison, the runtime of the access test on bare with this series
applied as-is is 10s with EPT enabled and 5s with EPT disabled. In a VM
I get 10s with EPT and 29s without.

> 
> If you don't object, I'll include FEP as a regular flag when applying.

My concerns are that the additional FEP access tests will push the
runtime over the 90s limit not only for my setup but for some CI setups
as well, as they are notoriously resource constraint (and I vaguely
remember a discussion about already hitting timeouts for the gitlab CI
pipeline?).

So yes, I do object. Please keep the AC_FEP_BIT excluded from the
ac_test_bump() tests. It'll cause trouble for CI setups, I'm certain.

> 
> 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).

Hehe, nice :D

> 
> 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;
> 

Thanks,
Mathias