Testcases for "eip canonical" kvm fixes?

Testcases for "eip canonical" kvm fixes?

[Denys Vlasenko]

Hi,

I wonder how did you trigger the bug for your following fix?


commit 234f3ce485d54017f15cf5e0699cff4100121601
Author: Nadav Amit <namit@cs.technion.ac.il>
Date:   Thu Sep 18 22:39:38 2014 +0300

    KVM: x86: Emulator fixes for eip canonical checks on near branches

    Before changing rip (during jmp, call, ret, etc.) the target
should be asserted
    to be canonical one, as real CPUs do.  During sysret, both target
rsp and rip
    should be canonical. If any of these values is noncanonical, a #GP exception
    should occur.  The exception to this rule are syscall and sysenter
instructions
    in which the assigned rip is checked during the assignment to the relevant
    MSRs.

    This patch fixes the emulator to behave as real CPUs do for near branches.
    Far branches are handled by the next patch.


Non-canonical addresses result in #GP, but KVM doesn't
intercept guest #GP, according to code below:

static void update_exception_bitmap(struct kvm_vcpu *vcpu)
{
        u32 eb;

        eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
             (1u << NM_VECTOR) | (1u << DB_VECTOR);
        if ((vcpu->guest_debug &
             (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
            (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
                eb |= 1u << BP_VECTOR;
        if (to_vmx(vcpu)->rmode.vm86_active)
                eb = ~0;
        if (enable_ept)
                eb &= ~(1u << PF_VECTOR); /* bypass_guest_pf = 0 */
        if (vcpu->fpu_active)
                eb &= ~(1u << NM_VECTOR);

        /* When we are running a nested L2 guest and L1 specified for it a
         * certain exception bitmap, we must trap the same exceptions and pass
         * them to L1. When running L2, we will only handle the exceptions
         * specified above if L1 did not want them.
         */
        if (is_guest_mode(vcpu))
                eb |= get_vmcs12(vcpu)->exception_bitmap;

        vmcs_write32(EXCEPTION_BITMAP, eb);
}


That what seems to be happening to me when I try to reproduce
the bug on unpatched kernel: CPU simply emulates #GP, and
everything works as it should.

In particular:
I'm trying "RET far" with noncanonical address on stack (and valid CS).
I expect that buggy behavior would be that #GP happens
after "RET far". Instead, #GP happens _on_ "RET far" insn.

-- 
vda

Re: Testcases for "eip canonical" kvm fixes?

[Nadav Amit]

Automatic testings. I am working on a research paper regarding it, so I’ll
publish the details (hopefully) in the near future.

Nadav

Denys Vlasenko <vda.linux@googlemail.com> wrote:

> Hi,
> 
> I wonder how did you trigger the bug for your following fix?
> 
> 
> commit 234f3ce485d54017f15cf5e0699cff4100121601
> Author: Nadav Amit <namit@cs.technion.ac.il>
> Date:   Thu Sep 18 22:39:38 2014 +0300
> 
>    KVM: x86: Emulator fixes for eip canonical checks on near branches
> 
>    Before changing rip (during jmp, call, ret, etc.) the target
> should be asserted
>    to be canonical one, as real CPUs do.  During sysret, both target
> rsp and rip
>    should be canonical. If any of these values is noncanonical, a #GP exception
>    should occur.  The exception to this rule are syscall and sysenter
> instructions
>    in which the assigned rip is checked during the assignment to the relevant
>    MSRs.
> 
>    This patch fixes the emulator to behave as real CPUs do for near branches.
>    Far branches are handled by the next patch.
> 
> 
> Non-canonical addresses result in #GP, but KVM doesn't
> intercept guest #GP, according to code below:
> 
> static void update_exception_bitmap(struct kvm_vcpu *vcpu)
> {
>        u32 eb;
> 
>        eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
>             (1u << NM_VECTOR) | (1u << DB_VECTOR);
>        if ((vcpu->guest_debug &
>             (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
>            (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
>                eb |= 1u << BP_VECTOR;
>        if (to_vmx(vcpu)->rmode.vm86_active)
>                eb = ~0;
>        if (enable_ept)
>                eb &= ~(1u << PF_VECTOR); /* bypass_guest_pf = 0 */
>        if (vcpu->fpu_active)
>                eb &= ~(1u << NM_VECTOR);
> 
>        /* When we are running a nested L2 guest and L1 specified for it a
>         * certain exception bitmap, we must trap the same exceptions and pass
>         * them to L1. When running L2, we will only handle the exceptions
>         * specified above if L1 did not want them.
>         */
>        if (is_guest_mode(vcpu))
>                eb |= get_vmcs12(vcpu)->exception_bitmap;
> 
>        vmcs_write32(EXCEPTION_BITMAP, eb);
> }
> 
> 
> That what seems to be happening to me when I try to reproduce
> the bug on unpatched kernel: CPU simply emulates #GP, and
> everything works as it should.
> 
> In particular:
> I'm trying "RET far" with noncanonical address on stack (and valid CS).
> I expect that buggy behavior would be that #GP happens
> after "RET far". Instead, #GP happens _on_ "RET far" insn.
> 
> -- 
> vda

Re: Testcases for "eip canonical" kvm fixes?

[Denys Vlasenko]

Hi Nadav,

On Wed, Mar 11, 2015 at 2:03 PM, Nadav Amit <nadav.amit@gmail.com> wrote:
> Automatic testings.

Are you willing to disclose your test harness?

I'm asking because it seems that stock kernels and stock qemu-kvm
can't reach code paths you are touching with your fixes.

Re: Testcases for "eip canonical" kvm fixes?

[Nadav Amit]

Denys Vlasenko <vda.linux@googlemail.com> wrote:

> Hi Nadav,
> 
> On Wed, Mar 11, 2015 at 2:03 PM, Nadav Amit <nadav.amit@gmail.com> wrote:
>> Automatic testings.
> 
> Are you willing to disclose your test harness?
> 
> I'm asking because it seems that stock kernels and stock qemu-kvm
> can't reach code paths you are touching with your fixes.

Unfortunately, I am not allowed (and will not be allowed) to release neither
the tests nor the test generator. We are working on continuing to run the
tests on a regular basis, but I cannot guarantee at the moment it will
happen.

Once I finish (finally) my research paper, I’ll push for it to happen and
update you.

Regards,
Nadav

Re: Testcases for "eip canonical" kvm fixes?

[Paolo Bonzini]

On 11/03/2015 14:27, Denys Vlasenko wrote:
> 
> I'm asking because it seems that stock kernels and stock qemu-kvm
> can't reach code paths you are touching with your fixes.

Some of Nadav's fixes have testcases for it in kvm-unit-tests, and more
can be added.

Paolo