Re: [Xen-devel] Doamin crash when trying to install disk encryption (PointSec) on Windows HVM

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

Patch is attached. It is in addition to the LTR/LLDT patch.

 -- Keir

On 23/04/2009 18:16, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx> wrote:

> A task switch reloads on segment registers, so it is impossible to enter
> vm86 mode with 'bad' segment state even via a task switch.
> 
> If the guest really is trying to enter vm86 mode via a task switch (which
> would be somewhat bizarre, although a valid thing to do) then
> hvm_load_segment_selector() needs updating to deal with VM86 mode. I'll make
> a patch.
> 
>  -- Keir
> 
> On 23/04/2009 17:10, "Tom Rotenberg" <tom.rotenberg@xxxxxxxxx> wrote:
> 
>> So, do u have any suggestion, on how can i fix this issue?
>> 
>> 2009/4/23 Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>> At 16:57 +0100 on 23 Apr (1240505849), Tom Rotenberg wrote:
>>>> Keir,
>>>> 
>>>> After further testing, it seems like the flow of events were like this:
>>>> there was a VMEXIT with the reason of task switch, which changed to
>>>> vm86mode
>>>> (!), and upon trying to resume from this vmexit, the cpu raised an
>>>> exception.
>>>> 
>>>> And the question is why and how did the task switch caused the vm86
>>>> mode to be turned on? is it even legal?
>>> 
>>> Yes, task-switching into vm86 mode is legal; ISTR it and IRET are the
>>> only ways mentioned in the SDMs of getting into vm86.
>>> 
>>> Looks like Xen doesn't support it, though.  It would need special
>>> handling of the segment state to get round the extra restrictions that
>>> Intel imposed on VMENTER (which are stricter than the limits on using
>>> vm86 mode unvirtualized).
>>> 
>>> Cheers,
>>> 
>>> Tim.
>>> 
>>>> Tom
>>>> 
>>>> 2009/4/23 Keir Fraser
>>>> <keir.fraser@xxxxxxxxxxxxx<mailto:keir.fraser@xxxxxxxxxxxxx>>
>>>> All task switches are emulated, so you can add tracing to hvm_task_switch()
>>>> to check if a switch has occurred. An alternative is that the guest did
>>>> another LTR while not being emulated?
>>>> 
>>>> If you want to remember the last VMEXIT, you?ll have to add code to store
>>>> state away somewhere to pick up on the next VMENTRY.
>>>> 
>>>>  -- Keir
>>>> 
>>>> 
>>>> On 23/04/2009 15:08, "Tom Rotenberg"
>>>> <tom.rotenberg@xxxxxxxxx<http://tom.rotenberg@xxxxxxxxx <http://gmail.com>
>>>>>> wrote:
>>>> 
>>>> About the TR, i have re-checked it, and it seems like the TR value is still
>>>> 0x58, althoug the LTR operation put 0x50 into it. Since, i looked at the
>>>> LTR
>>>> code you sent me, and it seems ok, i tend to suspect, that there was some
>>>> kind of (hardware) task switch, which changed the TR value without me
>>>> knowing, is it possible? because otherwise, i can't really explain why the
>>>> TR value is different than what was loaded from the LTR operation...
>>>> 
>>>> BTW - how can i track what was the previous VMEXIT before this last VMENTRY
>>>> which caused the exception? i think, that probably the last VMEXIT caused
>>>> the "change" to vm86 mode, and this is waht causes the problem...
>>>> 
>>>> Tom
>>>> 
>>>> 2009/4/23 Keir Fraser
>>>> <keir.fraser@xxxxxxxxxxxxx<http://keir.fraser@xxxxxxxxxxxxx
>>>> <http://eu.citrix.com> >>
>>>> On 23/04/2009 12:44, "Tom Rotenberg"
>>>> <tom.rotenberg@xxxxxxxxx<http://tom.rotenberg@xxxxxxxxx <http://gmail.com>
>>>>>> wrote:
>>>> 
>>>>> However, from the VMCS dump, i saw data, which doesn't seem compatible
>>>>> with
>>>>> this, as the LDTR sellector is indeed 0, but has attributes and limit
>>>>> different from zero (although it should have been totaly disabled, by the
>>>>> LLDT, no?).
>>>> 
>>>> The 'unused' flag in the attributes word is set (bit 16) so LDTR is okay.
>>>> 
>>>>> And more important, the TR selector is 0x58, although from the LTR, it was
>>>>> supposed to be 0x50, no?
>>>> 
>>>> If 0x50 was loaded then the selector should certainly be 0x50.
>>>> 
>>>>  -- Keir
>>>> 
>>>>> (of-course it's possible that there were other instructions who changed it
>>>>> back, however, i am wondering if there is a problem here).
>>>> 
>>>> 
>>>> 
>>> 
>>> --
>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
>>> Principal Software Engineer, Citrix Systems (R&D) Ltd.
>>> [Company #02300071, SL9 0DZ, UK.]
>> 
>

Attachment: 00-vm86_tswitch
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel