Vm handler problem

[fake-cheater]

void vmexit_passthrough_handler::handle_vm_fallback(vcpu_t& vp) noexcept {

//inject hardware exception must be write vmentryinslen vp.inject( interrupt_info_t(vmx::interrupt_type::hardware_exception, exception_vector::invalid_opcode)); //wtf this??? //inject ud exceptions does not require adding ins rip vp.suppress_rip_adjust();

}

void vcpu_t::entry_host() noexcept{ ........//// if (!suppress_ripadjust) { exitcontext.rip += exit_instruction_length(); } //if set Eflags.tf must be inject #DB exception if (exitcontext.rflags.trap_flag) {

      dr6_t dr6 = read<dr6_t>();
      dr6.single_instruction = true;
      write<dr6_t>(dr6);

      inject(interrupt_info_t(vmx::interrupt_type::hardware_exception,
        exception_vector::debug));

    }

   // anti blocking_movss
    vmx::interruptibility_state_t state = guest_interruptibility_state();
    state.blocking_by_mov_ss = false;
    state.blocking_by_sti = false;
    guest_interruptibility_state(state);

...../////// }

[wbenny]

Time to create issue templates, I guess :).

• Suppress adjusting RIP in handle_vm_fallback, good point, will fix
• Can you elaborate, please? Are we talking about a situation, when you switch EFLAGS.TF in VM-exit handler from 0 to 1? Are you sure that disabling interruptibility state is safe? Shouldn't we rather enable interrupt-window-exitting when the guest isn't interruptible and inject the #DB there?

[fake-cheater]

In addition to these problems, this vmm can also be detected by the ring3 layer. You can download wegame and test your vmm.. Tencent WeGameDownload link: https://www.wegame.com/

[fake-cheater]

There are also detection vectors for cr4/cr0 fixed bits, etc.

[fake-cheater]

Thank you baby, your open source project code style I like very much. :)