On 17/03/16 11:00, Jan Beulich wrote: >>>> On 17.03.16 at 11:45, <andrew.coop...@citrix.com> wrote: >> On 17/03/16 10:25, Jan Beulich wrote: >>>>>> On 16.03.16 at 21:05, <andrew.coop...@citrix.com> wrote: >>>> @@ -1742,8 +1742,10 @@ static void load_segments(struct vcpu *n) >>>> cs_and_mask = (unsigned short)regs->cs | >>>> ((unsigned int)vcpu_info(n, evtchn_upcall_mask) << 16); >>>> /* Fold upcall mask into RFLAGS.IF. */ >>>> - eflags = regs->_eflags & ~X86_EFLAGS_IF; >>>> + eflags = regs->_eflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL); >>> This and ... >>> >>>> @@ -1788,8 +1790,10 @@ static void load_segments(struct vcpu *n) >>>> ((unsigned long)vcpu_info(n, evtchn_upcall_mask) << 32); >>>> >>>> /* Fold upcall mask into RFLAGS.IF. */ >>>> - rflags = regs->rflags & ~X86_EFLAGS_IF; >>>> + rflags = regs->rflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL); >>> ... this is not really necessary (but also not wrong) - the actual >>> EFLAGS.IOPL is always zero (and assumed to be so by code >>> further down from the respective adjustments you make). For >>> consistency's sake it might be better to either drop the changes >>> here, or also adjust the two places masking regs->eflags. >> I will adjust the others. I would prefer not to rely on the assumption >> that it is actually 0. > But you realize that if it wasn't zero, we'd have a security issue?
Indeed. But as this adjustment is literally free for us to use, making Xen a little more robust in the (hopefully never) case were IOPL ends up not being 0. ~Andrew > (This notwithstanding I'm fine with both directions, as indicated > before.) > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
