On 07/04/2016 22:55, Jan Beulich wrote: >>>> On 07.04.16 at 23:39, <andrew.coop...@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 <jbeul...@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
