Wrong instruction after single-step exception with 'rdtsc'

[gim]

There was bug 5 years ago (#10947) and was fixed, but in current release still appears. Here slightly modified code with looping 1000000 times around RDTSC call with charged TF. If at least one call does not work correctly, a corresponding message is displayed:

      .586
      .model flat, stdcall
      option casemap :none   ; case sensitive

      include \masm32\include\windows.inc
      include \masm32\include\kernel32.inc
      include \masm32\include\user32.inc
      includelib \masm32\lib\kernel32.lib
      includelib \masm32\lib\user32.lib
     
.data
Flag	dd 0
Address dd 0
Counter dd 0
szRight	db 'Flag Value is right!, address = 0x%lx, counter = %ld',0
szWrong	db 'Flag Value is wrong!, address = 0x%lx, counter = %ld',0
szMessage db 256 dup(0)
    
szInfo	db 'Info:'

.code
start:
	assume fs: nothing
test_loop:
	call @MyCode
	mov     ecx, dword ptr [esp+0Ch]
	mov 	ecx, dword ptr [ecx+0B8h]	;;Ecx = Seh.eip
        mov     Address, ecx
	.if ecx == offset @WrongExceptionEip
		mov Flag,0
	.else
		mov Flag,1
	.endif
	xor     eax, eax
	retn
	@MyCode:
	push    dword ptr fs:[0]
	mov     dword ptr fs:[0], esp
	push 397h             ;;Set Eflags
	popfd
	rdtsc
	@RightExceptionEip:		;;Normally,Seh.eip should be pointed here
	nop
	@WrongExceptionEip:		;;In Guest system,('Without' VT-X/AMD-V),Seh.eip is pointed here.But 'With' VT-X/AMD-V,Seh.eip is right.
        cmp Flag, 1
        jnz flag_wrong
        pop eax
        pop fs:[0]
        inc Counter
        cmp Counter, 1000000
        jnz test_loop
        invoke wsprintf,offset szMessage, offset szRight, Address, Counter
        jmp exit
flag_wrong:
        invoke wsprintf,offset szMessage, offset szWrong, Address, Counter
exit:
        invoke MessageBoxA,0,offset szMessage,offset szInfo,MB_OK
	invoke ExitProcess,0
end start

(compiled sample attached rdtsc.exe)

For example, in the real world, this misbehavior is used by the vmprotect to detect a virtual machine. I hope there is no good program crashing because of this misbehavior...

[gim]

compiled asm code

[gim]

And this problem appears with VT-X/AMD-V too on any Windows OS

[gim]

up

[michaln]

Please provide a VBox.log from a VM showing the problem. It would not hurt to specify what "any" Windows OS is either. Windows 3.1? Windows 95? Windows 10 64-bit?

[gim]

I've attached VBox.log and proof screenshot. But I believe that you could not find any usefully info inside VBox.log without enabling R0-logging or at least some VBOX RELEASE LOGGING flags. The problem probably lies somewhere deeply in VMM.

About OSes. We can confirm for Linux/Windows hosts with Windows XP, Windows 7 and Windows 10 guests for sure with latest VirtualBox 5.2.8. For others OSes we can't confirm, but you can check by self, I think it will reproduce.

[gim]

up

[gim]

up