On 15/09/2016 07:28, Jan Beulich wrote:
>>>> On 14.09.16 at 19:12, <andrew.coop...@citrix.com> wrote:
>> On 14/09/16 16:24, Jan Beulich wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -1745,22 +1745,22 @@ static void load_segments(struct vcpu *n
>>>              (unsigned long *)pv->kernel_sp;
>>>          unsigned long cs_and_mask, rflags;
>>>  
>>> +        /* Fold upcall mask and architectural IOPL into RFLAGS.IF. */
>>> +        rflags  = regs->rflags & ~(X86_EFLAGS_IF|X86_EFLAGS_IOPL);
>>> +        rflags |= !vcpu_info(n, evtchn_upcall_mask) << 9;
>>> +        if ( VM_ASSIST(n->domain, architectural_iopl) )
>>> +            rflags |= n->arch.pv_vcpu.iopl;
>>> +
>>>          if ( is_pv_32bit_vcpu(n) )
>>>          {
>>>              unsigned int *esp = ring_1(regs) ?
>>>                                  (unsigned int *)regs->rsp :
>>>                                  (unsigned int *)pv->kernel_sp;
>>> -            unsigned int cs_and_mask, eflags;
>> The unshadowed cs_and_mask is unsigned long, not int, which means the
>> put_user() below will clobber a 32bit PV guests stack frame.
> No, put_user() determines the access size from its second (pointer)
> argument.

Oh - so it does.  Mind putting at least note to that effect in the
commit message?  My first thought upon seeing it was wondering whether
you had a stale patch which didn't compile.

With that, Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>

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

Reply via email to