Hi,
It looks like gmail silently failed to attach the file and didn't
even notify me about this. I reattached my program in this message.
It was compiled with MASM using attached script and tested under
Windows XP SP3 host and guest.
Here's the bat file I used for compilation (I cannot attach such files):
@REM Make sure this path is correct before attempting to build
@set MASM_PATH=C:\masm32
@set PATH=%PATH%;%MASM_PATH%\bin
ml -c -coff -I%MASM_PATH%\include 10947_test.asm
link /ENTRY:start /SUBSYSTEM:CONSOLE /LIBPATH:%MASM_PATH%\lib
10947_test.obj
Regards,
Konrad
2013/11/12 Ramshankar <[email protected]
<mailto:[email protected]>>
Hi,
You said in the attachment, you have included a testcase, I can't
find any attachment in your original email. Could you please
re-attach it?
Regards,
Ram.
On 11/09/2013 05:01 AM, Ramshankar wrote:
Hi,
Thank you for the patch. I'll take a look at it next week.
Regards,
Ram.
On 08/11/13 22:13, Konrad Kuźmiński wrote:
Hi,
I've made a fix for this bug
https://www.virtualbox.org/ticket/10947.
Mentioned ticket isn't very descriptive so I will try to
explain this
issue a little bit more in detail. First of all this
problem occurs only
when VT-x is enabled. Basically some instructions don't
generate
expected single step exception after they are executed
with the trap
flag being set. The behaviour is observed that such
instructions are
executed under the control of the guest system but single
step exception
is generated after the next instruction. This is a well
known bug
amongst malware researchers and malware authors who can
easily take
advantage of this fact in order to detect virtualized
environment.
It turns out that the problem lies in the way VirtualBox
handles some VM
exits initiated by the execution of certain instructions.
Several
instructions can never be executed in VMX non-root
operation and those
need to be emulated and skipped within VM exit handlers
by adjusting
RIP. Unfortunately the code lacks necessary check for the
trap flag
being set, so it doesn't inject expected exception into
the guest.
Here's the fix:
*** src\VBox\VMM\VMMR0\HMVMXR0_original.cpp 2013-11-01
18:58:26.000000000 +0100
--- src\VBox\VMM\VMMR0\HMVMXR0_fixed.cpp 2013-11-08
20:24:30.578125000 +0100
***************
*** 8166,8181 ****
--- 8166,8190 ----
DECLINLINE(int) hmR0VmxAdvanceGuestRip(PVMCPU pVCpu,
PCPUMCTX
pMixedCtx, PVMXTRANSIENT pVmxTransient)
{
int rc = hmR0VmxReadExitInstrLenVmcs(pVCpu,
pVmxTransient);
rc |= hmR0VmxSaveGuestRip(pVCpu, pMixedCtx);
AssertRCReturn(rc, rc);
pMixedCtx->rip += pVmxTransient->cbInstr;
VMCPU_HMCF_SET(pVCpu, HM_CHANGED_GUEST_RIP);
+
+ X86EFLAGS Eflags;
+ rc = VMXReadVmcs32(VMX_VMCS_GUEST_RFLAGS, &Eflags.u32);
+ AssertRCReturn(rc, rc);
+ if (Eflags.Bits.u1TF)
+ {
+ hmR0VmxSetPendingXcptDB(pVCpu, pMixedCtx);
+ }
+
return rc;
}
This fix ensures correct handling of mentioned condition
in all 13
affected VM exit handlers: VMX_EXIT_CPUID, VMX_EXIT_RDTSC,
VMX_EXIT_RDTSCP, VMX_EXIT_RDPMC, VMX_EXIT_MOV_CRX,
VMX_EXIT_MOV_DRX,
VMX_EXIT_MWAIT, VMX_EXIT_MONITOR, VMX_EXIT_RDMSR,
VMX_EXIT_WRMSR,
VMX_EXIT_INVD, VMX_EXIT_INVLPG, VMX_EXIT_WBINVD.
In the attachment I provided a simple program which can
be used to test
this condition on 2 representative instructions: CPUID
and RDTSC. I
picked those because they don't require CPL = 0.
I release this patch and test program under MIT license.
Best regards,
Konrad
_______________________________________________
vbox-dev mailing list
[email protected] <mailto:[email protected]>
https://www.virtualbox.org/mailman/listinfo/vbox-dev
_______________________________________________
vbox-dev mailing list
[email protected] <mailto:[email protected]>
https://www.virtualbox.org/mailman/listinfo/vbox-dev
