>>> On 08.04.16 at 00:30, <andrew.coop...@citrix.com> wrote: > 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?
Because there's no reason to clear AC for 32-bit guests. > 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. Not sure what meaning of "task switch" you're implying here - we're talking about code dealing with certain failures in the PV context switch path, which has nothing to do with hardware task switching. > 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. Nor do I understand your reference to leaking whatever state into user space: We're injecting a failsafe callback here, i.e. guest execution is guaranteed to resume in kernel space. The difference here mirrors the difference between compat_create_bounce_frame and create_bounce_frame in regard to what parts of EFLAGS they clear. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
