From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Doamin crash when trying to install disk encryption (PointSec) on Windows HVM Date: Thu, 23 Apr 2009 18:27:00 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="B_3323356022_7338539" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tom Rotenberg , Tim Deegan Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3323356022_7338539 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Patch is attached. It is in addition to the LTR/LLDT patch. -- Keir On 23/04/2009 18:16, "Keir Fraser" 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. >=20 > 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 m= ake > a patch. >=20 > -- Keir >=20 > On 23/04/2009 17:10, "Tom Rotenberg" wrote: >=20 >> So, do u have any suggestion, on how can i fix this issue? >>=20 >> 2009/4/23 Tim Deegan >>> At 16:57 +0100 on 23 Apr (1240505849), Tom Rotenberg wrote: >>>> Keir, >>>>=20 >>>> 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. >>>>=20 >>>> And the question is why and how did the task switch caused the vm86 >>>> mode to be turned on? is it even legal? >>>=20 >>> Yes, task-switching into vm86 mode is legal; ISTR it and IRET are the >>> only ways mentioned in the SDMs of getting into vm86. >>>=20 >>> Looks like Xen doesn't support it, though. =A0It 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). >>>=20 >>> Cheers, >>>=20 >>> Tim. >>>=20 >>>> Tom >>>>=20 >>>> 2009/4/23 Keir Fraser >>>> > >>>> All task switches are emulated, so you can add tracing to hvm_task_swi= tch() >>>> to check if a switch has occurred. An alternative is that the guest di= d >>>> another LTR while not being emulated? >>>>=20 >>>> If you want to remember the last VMEXIT, you?ll have to add code to st= ore >>>> state away somewhere to pick up on the next VMENTRY. >>>>=20 >>>> =A0-- Keir >>>>=20 >>>>=20 >>>> On 23/04/2009 15:08, "Tom Rotenberg" >>>> >>>>>> wrote: >>>>=20 >>>> 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 t= he >>>> LTR >>>> code you sent me, and it seems ok, i tend to suspect, that there was s= ome >>>> 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... >>>>=20 >>>> BTW - how can i track what was the previous VMEXIT before this last VM= ENTRY >>>> which caused the exception? i think, that probably the last VMEXIT cau= sed >>>> the "change" to vm86 mode, and this is waht causes the problem... >>>>=20 >>>> Tom >>>>=20 >>>> 2009/4/23 Keir Fraser >>>> >>> >> >>>> On 23/04/2009 12:44, "Tom Rotenberg" >>>> >>>>>> wrote: >>>>=20 >>>>> However, from the VMCS dump, i saw data, which doesn't seem compatibl= e >>>>> 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?). >>>>=20 >>>> The 'unused' flag in the attributes word is set (bit 16) so LDTR is ok= ay. >>>>=20 >>>>> And more important, the TR selector is 0x58, although from the LTR, i= t was >>>>> supposed to be 0x50, no? >>>>=20 >>>> If 0x50 was loaded then the selector should certainly be 0x50. >>>>=20 >>>> =A0-- Keir >>>>=20 >>>>> (of-course it's possible that there were other instructions who chang= ed it >>>>> back, however, i am wondering if there is a problem here). >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> -- >>> Tim Deegan >>> Principal Software Engineer, Citrix Systems (R&D) Ltd. >>> [Company #02300071, SL9 0DZ, UK.] >>=20 >=20 --B_3323356022_7338539 Content-type: application/octet-stream; name="00-vm86_tswitch" Content-disposition: attachment; filename="00-vm86_tswitch" Content-transfer-encoding: base64 ZGlmZiAtciA4YjE1MjYzOGFkYWEgeGVuL2FyY2gveDg2L2h2bS9odm0uYwotLS0gYS94ZW4v YXJjaC94ODYvaHZtL2h2bS5jCVRodSBBcHIgMjMgMTY6MjI6NDggMjAwOSArMDEwMAorKysg Yi94ZW4vYXJjaC94ODYvaHZtL2h2bS5jCVRodSBBcHIgMjMgMTg6MjU6NDkgMjAwOSArMDEw MApAQCAtMTE4OCwxMiArMTE4OCwyNCBAQAogfQogCiBzdGF0aWMgaW50IGh2bV9sb2FkX3Nl Z21lbnRfc2VsZWN0b3IoCi0gICAgc3RydWN0IHZjcHUgKnYsIGVudW0geDg2X3NlZ21lbnQg c2VnLCB1aW50MTZfdCBzZWwpCisgICAgZW51bSB4ODZfc2VnbWVudCBzZWcsIHVpbnQxNl90 IHNlbCkKIHsKICAgICBzdHJ1Y3Qgc2VnbWVudF9yZWdpc3RlciBkZXNjdGFiLCBjcywgc2Vn cjsKICAgICBzdHJ1Y3QgZGVzY19zdHJ1Y3QgKnBkZXNjLCBkZXNjOwogICAgIHU4IGRwbCwg cnBsLCBjcGw7CiAgICAgaW50IGZhdWx0X3R5cGUgPSBUUkFQX2ludmFsaWRfdHNzOworICAg IHN0cnVjdCBjcHVfdXNlcl9yZWdzICpyZWdzID0gZ3Vlc3RfY3B1X3VzZXJfcmVncygpOwor ICAgIHN0cnVjdCB2Y3B1ICp2ID0gY3VycmVudDsKKworICAgIGlmICggcmVncy0+ZWZsYWdz ICYgRUZfVk0gKQorICAgIHsKKyAgICAgICAgc2Vnci5zZWwgPSBzZWw7CisgICAgICAgIHNl Z3IuYmFzZSA9ICh1aW50MzJfdClzZWwgPDwgNDsKKyAgICAgICAgc2Vnci5saW1pdCA9IDB4 ZmZmZnU7CisgICAgICAgIHNlZ3IuYXR0ci5ieXRlcyA9IDB4ZjM7CisgICAgICAgIGh2bV9z ZXRfc2VnbWVudF9yZWdpc3Rlcih2LCBzZWcsICZzZWdyKTsKKyAgICAgICAgcmV0dXJuIDA7 CisgICAgfQogCiAgICAgLyogTlVMTCBzZWxlY3Rvcj8gKi8KICAgICBpZiAoIChzZWwgJiAw eGZmZmMpID09IDAgKQpAQCAtMTQ0MCwxMyArMTQ1MiwxMyBAQAogICAgIH0KIAogICAgIGV4 bl9yYWlzZWQgPSAwOwotICAgIGlmICggaHZtX2xvYWRfc2VnbWVudF9zZWxlY3Rvcih2LCB4 ODZfc2VnX2VzLCB0c3MuZXMpIHx8Ci0gICAgICAgICBodm1fbG9hZF9zZWdtZW50X3NlbGVj dG9yKHYsIHg4Nl9zZWdfY3MsIHRzcy5jcykgfHwKLSAgICAgICAgIGh2bV9sb2FkX3NlZ21l bnRfc2VsZWN0b3IodiwgeDg2X3NlZ19zcywgdHNzLnNzKSB8fAotICAgICAgICAgaHZtX2xv YWRfc2VnbWVudF9zZWxlY3Rvcih2LCB4ODZfc2VnX2RzLCB0c3MuZHMpIHx8Ci0gICAgICAg ICBodm1fbG9hZF9zZWdtZW50X3NlbGVjdG9yKHYsIHg4Nl9zZWdfZnMsIHRzcy5mcykgfHwK LSAgICAgICAgIGh2bV9sb2FkX3NlZ21lbnRfc2VsZWN0b3IodiwgeDg2X3NlZ19ncywgdHNz LmdzKSB8fAotICAgICAgICAgaHZtX2xvYWRfc2VnbWVudF9zZWxlY3Rvcih2LCB4ODZfc2Vn X2xkdHIsIHRzcy5sZHQpICkKKyAgICBpZiAoIGh2bV9sb2FkX3NlZ21lbnRfc2VsZWN0b3Io eDg2X3NlZ19lcywgdHNzLmVzKSB8fAorICAgICAgICAgaHZtX2xvYWRfc2VnbWVudF9zZWxl Y3Rvcih4ODZfc2VnX2NzLCB0c3MuY3MpIHx8CisgICAgICAgICBodm1fbG9hZF9zZWdtZW50 X3NlbGVjdG9yKHg4Nl9zZWdfc3MsIHRzcy5zcykgfHwKKyAgICAgICAgIGh2bV9sb2FkX3Nl Z21lbnRfc2VsZWN0b3IoeDg2X3NlZ19kcywgdHNzLmRzKSB8fAorICAgICAgICAgaHZtX2xv YWRfc2VnbWVudF9zZWxlY3Rvcih4ODZfc2VnX2ZzLCB0c3MuZnMpIHx8CisgICAgICAgICBo dm1fbG9hZF9zZWdtZW50X3NlbGVjdG9yKHg4Nl9zZWdfZ3MsIHRzcy5ncykgfHwKKyAgICAg ICAgIGh2bV9sb2FkX3NlZ21lbnRfc2VsZWN0b3IoeDg2X3NlZ19sZHRyLCB0c3MubGR0KSAp CiAgICAgICAgIGV4bl9yYWlzZWQgPSAxOwogCiAgICAgcmMgPSBodm1fY29weV90b19ndWVz dF92aXJ0KAo= --B_3323356022_7338539 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --B_3323356022_7338539--