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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 08.04.16 at 00:30, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 07/04/2016 22:55, Jan Beulich wrote:
>>>>> On 07.04.16 at 23:39, <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxx>
> 
> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel