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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 07/04/2016 22:55, Jan Beulich wrote:
>>>> On 07.04.16 at 23:39, <andrew.cooper3@citrix.com> wrote:
>> @@ -1763,7 +1765,8 @@ static void load_segments(struct vcpu *n)
>>                  vcpu_info(n, evtchn_upcall_mask) = 1;
>>  
>>              regs->entry_vector |= TRAP_syscall;
>> -            regs->_eflags      &= 0xFFFCBEFFUL;
>> +            regs->_eflags      &= ~(X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|
>> +                                    X86_EFLAGS_NT|X86_EFLAGS_IOPL|X86_EFLAGS_TF);
> Why AC, which didn't get cleared before? Did you just copy
> the 64-bit variant from below?

Yes,

> Assuming so, with it removed Reviewed-by: Jan Beulich <jbeulich@suse.com>

Why keep the disparity?

Looking this up again, architecturally speaking, its wrong.  AC does not
get cleared on a 32 or 64bit task switch; It only gets cleared on a real
mode task switch.

I presume you are refering to c/s eb97b7dc2b "[XEN] Fix x86/64 bug where
a guest application can crash the guest OS by setting AC flag in
RFLAGS.", from 2006?  Such a PV VM is already vulnerable from other
means.  I suppose this explains why 32bit PV kernels end up leaking AC
back into userspace.

Yuck - yet more non-architectural and non-documented PV ABI caused by
Xen trying to bugfix its way around broken PV kernels.

~Andrew

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