On Tue, May 25, 2010 at 12:37 PM, Avi Kivity <avi@xxxxxxxxxx> wrote: > On 05/13/2010 11:15 PM, Mohammed Gamal wrote: >> >> On Thu, May 13, 2010 at 9:24 AM, Avi Kivity<avi@xxxxxxxxxx> wrote: >> >>> >>> On 05/11/2010 07:52 PM, Mohammed Gamal wrote: >>> >>>> >>>> - Add 's' and 'g' field checks on segment registers >>>> - Correct SS checks for request and descriptor privilege levels >>>> >>>> Signed-off-by: Mohammed Gamal<m.gamal005@xxxxxxxxx> >>>> --- >>>> arch/x86/kvm/vmx.c | 73 >>>> +++++++++++++++++++++++++++++++++++++++++++++++---- >>>> 1 files changed, 67 insertions(+), 6 deletions(-) >>>> >>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>>> index 777e00d..9805c2a 100644 >>>> --- a/arch/x86/kvm/vmx.c >>>> +++ b/arch/x86/kvm/vmx.c >>>> @@ -2121,16 +2121,30 @@ static bool stack_segment_valid(struct kvm_vcpu >>>> *vcpu) >>>> vmx_get_segment(vcpu,&ss, VCPU_SREG_SS); >>>> ss_rpl = ss.selector& SELECTOR_RPL_MASK; >>>> >>>> - if (ss.unusable) >>>> + if (ss.dpl != ss_rpl) /* DPL != RPL */ >>>> + return false; >>>> + >>>> + if (ss.unusable) /* Short-circuit */ >>>> return true; >>>> >>>> >>> >>> If ss.unusable, do the dpl and rpl have any meaning? >>> >> >> The idea is that dpl and rpl are checked on vmentry regardless of >> whether ss is usable or not. While the other checks are performed only >> if ss is usable. >> > > Any reference to back this up? I think rpl is valid regardless of > ss.unusable (i.e. loading selector 0003 results in an unusable segment with > rpl=3), but I don't see how dpl can be valid in an unusable segment. > Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 3B, System Programming Guide, Part 2, Chapter 22, Section 22.3.1.2: Checks on Guest Segment Registers. You'll note that DS, ES, FS, GS checks are done when the segment is usable. SS checks are not necessarily checked only when the segment is usable. > -- > error compiling committee.c: too many arguments to function > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
