RE: [Xen-devel] more segment/selector handling woes

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jan Beulich
> Sent: 22 November 2006 11:45
> To: Petersson, Mats
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] more segment/selector handling woes
> 
> >> Not only on VMX and in generic code, but also on SVM now:
> >> svm_get_io_address() uses the segment base only when the guest
> >> is not in long mode - what if outs has an fs/gs override? 
> I'm pretty
> >> sure the base address is needed then, which opens the question -
> >> does the CPU guarantee a valid (zero) base also for the other
> >> segment register, or does this need to be conditionalized?
> >
> >Good question. I think you've found a bug, fs/gs should be taken into
> >consideration in 64-bit mode. 
> >
> >The x86-64 architecture "guarantees" that the base is zero 
> in long-mode.
> >
> >
> >More precisely, page 110 in the December 2005 AMD64 PRM Vol 2:
> >* In data-segment descriptors referenced by DS, ES and SS segment
> >registers, the base-address field is ignored,. For the purpose of
> >virtual-address calculations, the base address is treates as 
> if it has a
> >value of zero. 
> 
> Note the wording 'as if' - this doesn't tell me whether the 
> internal base
> address field (which gets stored to the vmcb) can indeed be 
> relied upon.
> But obviously the code would be simpler if that was the case 
> in reality
> (and then perhaps the documentation could be updated accordingly).
> 
> >> Further, in the same function (and likely elsewhere) the injection
> >> of GP faults seems pretty pointless - if either of the two
> >> conditions is true, then the CPU itself should have raised a GP
> >> fault for the guest already (i.e. execution flow would never get
> >> here).
> >
> >INS/OUTS will be checked by the processor for the first 
> access only in
> >the virtualized case, whilst the range is checked on every 
> iteration of
> >the instruction in the "real" processor case. Since we only take one
> >intercept for the first operation and then does as much as 
> possible (up
> >to a page boundary), it's possible that the code would be faulty and
> >make GP fault on the consecutive accesses. Of course, if you 
> trust the
> >code to be correct, then it's fine to eliminat the GP fault 
> checking -
> >but I put those in there to make sure that the virtual model 
> is as close
> >to the real processor as possible. They shouldn't fire very 
> often, I'm
> >sure... ;-)
> 
> But that isn't really done: svm_get_io_address() gets called once
> from svm_io_instruction(), and then up to a full page is being copied.
> The next part is copied only after having returned to the guest and
> having received the next exit.
> Further, even if the checks were done for each iteration, the present
> bit check would still be useless, only the limit check then 
> is relevant
> (and should supposedly be done only when count > 1).

I agree that the limit check is the "necessary" part of the check. There
is no need to check present, as that's (unless someone is changing the
descriptor table - and even so, it wouldn't really make any difference,
as the VMCB wouldn't get filled with the not-present segment, as the
processor would GP-fault FIRST...) already been checked by the
processor. 

Count = 0 .. 1 is a rare case, so checking if count > 1 is probably
meaningless....

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



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