Re: [Xen-devel] Bisected Xen-unstable: "Segment register inaccessible for d1v0" when starting HVM guest on intel

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.07.14 at 07:05, <feng.wu@xxxxxxxxx> wrote:
>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>> During a context switch (where the vmcs is unavailable), we try to
>> update the the runstate area.
>> 
>> Following the identified changeset, we unconditionally try to read ss
>> for an hvm vcpu supervisor access, but in this case we don't actually
>> have a pagefault.
>> 
>> I think there might need to be a distinction between "Xen is walking the
>> guest pagetables because of a fault", and "Xen is walking the guest
>> pagetables in an attempt to copy_to/from_guest".  Neither SMEP or SMAP
>> have any business being checked for a Xen accesses; the current vcpu
>> operating mode has no bearing on whether Xen should be able to update
>> the runstate info.
> 
> Seems we cannot get the guest SS here by hvm_get_segment_register(), since 
> in this case this function will be called between setting 'current' and 
> vmx_do_resume(). Is the following solution okay to solve this issue:
> 
> 1. Store GUEST_SS to regs->ss in vmx_vmexit_handler() just like what has been 
> done for GUEST_RIP/ GUEST_RSP/ GUEST_RFLAGS.
> 2. Get the guest SS from struct cpu_user_regs in guest_walk_tables()

I think you originally (and wrongly) did this via looking at the RPL;
this won't all of the sudden become right now. DPL is the only
thing you can use for the judgment, and that can't be read
without calling hvm_get_segment_register() (unless we latched
that while scheduling a vCPU out). But as Andrew validly said,
for the purposes of out of context Xen writes the guest execution
mode doesn't matter anyway, these ought to always assume
supervisor mode. That points out another problem here: Accesses
like the setting of a segment descriptor's accessed bit or the A/D
bit in a page table entry also need to be done as if in supervisor
mode, i.e. we need some kind of mode override also for other
purposes. Yet I don't think that's going to be too intrusive a
change: Everything here happens on "current", i.e. we can set
and clear a mode override on the respective call paths.

But then again - why do we need to determine CPL here anyway?
PFEC_user_mode clear already tells us the access was a kernel
mode one. And the SMEP check doesn't look at CPL, only the SMAP
one does.

Jan


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