<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/12/2013 05:13 PM, Ramshankar
wrote:<br>
</div>
<blockquote cite="mid:528253BA.8050400@oracle.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi,<br>
<br>
Thanks for the testcase. I took a look at your patch and the
testcase.<br>
<br>
I don't think injecting #DB directly the way you're suggesting
is the right thing to do. The right fix, as far as I can see,
would be to setup the pending debug exceptions VMCS field, that
way VMX injects the #DB taking into account the priority of
exceptions.<br>
<br>
The fix would be to simply remove the "if (fBlockSti ||
fBlockMovSS)" in hmR0VmxInjectPendingEvent() but I've not yet
tested if it works. Once I test that it works, I'll do the
needful. I need to verify that I'm not screwing up something
else in the block-by-STI and block-by-MovSS scenarios.<br>
<br>
Thanks again for the patch!<br>
<br>
</div>
</blockquote>
<br>
Oh and you'll have to call hmR0VmxSaveGuestRflags() before the "if
(pMixedCtx->eflags.Bits.u1TF)" check in
hmR0VmxInjectPendingEvent().<br>
<br>
<blockquote cite="mid:528253BA.8050400@oracle.com" type="cite">
<div class="moz-cite-prefix"> Regards,<br>
Ram.<br>
<br>
<br>
On 11/12/2013 01:44 PM, Konrad Kuźmiński wrote:<br>
</div>
<blockquote
cite="mid:CAMk0anePBLGTBP9OhWi9=iMJUJWqp4tYNXW4R0teoqP4oXcPaA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>Hi,<br>
<br>
</div>
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.<br>
<br>
</div>
<div>Here's the bat file I used for compilation (I cannot
attach such files):<br>
</div>
<div><span style="font-family:courier new,monospace">@REM
Make sure this path is correct before attempting to
build<br>
@set MASM_PATH=C:\masm32<br>
@set PATH=%PATH%;%MASM_PATH%\bin<br>
<br>
ml -c -coff -I%MASM_PATH%\include 10947_test.asm<br>
link /ENTRY:start /SUBSYSTEM:CONSOLE
/LIBPATH:%MASM_PATH%\lib 10947_test.obj</span><br>
<br>
</div>
Regards,<br>
</div>
Konrad<br>
<div>
<div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/11/12 Ramshankar <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:ramshankar.venkataraman@oracle.com"
target="_blank">ramshankar.venkataraman@oracle.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
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?<br>
<br>
Regards,<br>
Ram.
<div class="">
<div class="h5"><br>
<br>
On 11/09/2013 05:01 AM, Ramshankar wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> Hi,<br>
<br>
Thank you for the patch. I'll take a look
at it next week.<br>
<br>
Regards,<br>
Ram.<br>
<br>
On 08/11/13 22:13, Konrad Kuźmiński wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> Hi,<br>
<br>
I've made a fix for this bug <a
moz-do-not-send="true"
href="https://www.virtualbox.org/ticket/10947"
target="_blank">https://www.virtualbox.org/ticket/10947</a>.<br>
Mentioned ticket isn't very descriptive
so I will try to explain this<br>
issue a little bit more in detail. First
of all this problem occurs only<br>
when VT-x is enabled. Basically some
instructions don't generate<br>
expected single step exception after
they are executed with the trap<br>
flag being set. The behaviour is
observed that such instructions are<br>
executed under the control of the guest
system but single step exception<br>
is generated after the next instruction.
This is a well known bug<br>
amongst malware researchers and malware
authors who can easily take<br>
advantage of this fact in order to
detect virtualized environment.<br>
<br>
It turns out that the problem lies in
the way VirtualBox handles some VM<br>
exits initiated by the execution of
certain instructions. Several<br>
instructions can never be executed in
VMX non-root operation and those<br>
need to be emulated and skipped within
VM exit handlers by adjusting<br>
RIP. Unfortunately the code lacks
necessary check for the trap flag<br>
being set, so it doesn't inject expected
exception into the guest.<br>
<br>
Here's the fix:<br>
***
src\VBox\VMM\VMMR0\HMVMXR0_original.cpp
2013-11-01<br>
18:58:26.000000000 +0100<br>
--- src\VBox\VMM\VMMR0\HMVMXR0_fixed.cpp
2013-11-08<br>
20:24:30.578125000 +0100<br>
***************<br>
*** 8166,8181 ****<br>
--- 8166,8190 ----<br>
DECLINLINE(int)
hmR0VmxAdvanceGuestRip(PVMCPU pVCpu,
PCPUMCTX<br>
pMixedCtx, PVMXTRANSIENT pVmxTransient)<br>
{<br>
int rc =
hmR0VmxReadExitInstrLenVmcs(pVCpu,
pVmxTransient);<br>
rc |=
hmR0VmxSaveGuestRip(pVCpu, pMixedCtx);<br>
AssertRCReturn(rc, rc);<br>
<br>
pMixedCtx->rip +=
pVmxTransient->cbInstr;<br>
VMCPU_HMCF_SET(pVCpu,
HM_CHANGED_GUEST_RIP);<br>
+<br>
+ X86EFLAGS Eflags;<br>
+ rc =
VMXReadVmcs32(VMX_VMCS_GUEST_RFLAGS,
&Eflags.u32);<br>
+ AssertRCReturn(rc, rc);<br>
+ if (Eflags.Bits.u1TF)<br>
+ {<br>
+ hmR0VmxSetPendingXcptDB(pVCpu,
pMixedCtx);<br>
+ }<br>
+<br>
return rc;<br>
}<br>
<br>
This fix ensures correct handling of
mentioned condition in all 13<br>
affected VM exit handlers:
VMX_EXIT_CPUID, VMX_EXIT_RDTSC,<br>
VMX_EXIT_RDTSCP, VMX_EXIT_RDPMC,
VMX_EXIT_MOV_CRX, VMX_EXIT_MOV_DRX,<br>
VMX_EXIT_MWAIT, VMX_EXIT_MONITOR,
VMX_EXIT_RDMSR, VMX_EXIT_WRMSR,<br>
VMX_EXIT_INVD, VMX_EXIT_INVLPG,
VMX_EXIT_WBINVD.<br>
<br>
In the attachment I provided a simple
program which can be used to test<br>
this condition on 2 representative
instructions: CPUID and RDTSC. I<br>
picked those because they don't require
CPL = 0.<br>
<br>
I release this patch and test program
under MIT license.<br>
<br>
Best regards,<br>
Konrad<br>
<br>
<br>
_______________________________________________<br>
vbox-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:vbox-dev@virtualbox.org"
target="_blank">vbox-dev@virtualbox.org</a><br>
<a moz-do-not-send="true"
href="https://www.virtualbox.org/mailman/listinfo/vbox-dev"
target="_blank">https://www.virtualbox.org/mailman/listinfo/vbox-dev</a><br>
<br>
</blockquote>
<br>
_______________________________________________<br>
vbox-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:vbox-dev@virtualbox.org"
target="_blank">vbox-dev@virtualbox.org</a><br>
<a moz-do-not-send="true"
href="https://www.virtualbox.org/mailman/listinfo/vbox-dev"
target="_blank">https://www.virtualbox.org/mailman/listinfo/vbox-dev</a><br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
vbox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:vbox-dev@virtualbox.org">vbox-dev@virtualbox.org</a>
<a class="moz-txt-link-freetext" href="https://www.virtualbox.org/mailman/listinfo/vbox-dev">https://www.virtualbox.org/mailman/listinfo/vbox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>