Re: [Xen-devel] [PATCH 2/2] xen/x86: Introduce a new VMASSIST for architectural behaviour of iopl

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.03.16 at 11:45, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 17/03/16 10:25, Jan Beulich wrote:
>>>>> On 16.03.16 at 21:05, <andrew.cooper3@xxxxxxxxxx> 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?
(This notwithstanding I'm fine with both directions, as indicated
before.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel