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

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Tuesday, July 01, 2014 5:40 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Sander Eikelenboom; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] Bisected Xen-unstable: "Segment register inaccessible
> for d1v0" when starting HVM guest on intel
> 
> >>> On 01.07.14 at 11:03, <feng.wu@xxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >>> On 01.07.14 at 07:05, <feng.wu@xxxxxxxxx> wrote:
> >> > 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
> >
> > So according to you and Andrew's comments, maybe we can add a
> > parameter for guest_walk_tables() to distinguish "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". We only do the
> > SMAP/SMEP check for the guest fault case?
> 
> I don't think such a flag would yield correct behavior - see below.
> 
> >> 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.
> >
> > I am sorry, I don't quite understand about the problem you mentioned here,
> > Could you please elaborate a bit more on it? Thanks a lot!
> 
> This is referring to exactly what you quote below - implicit supervisor
> mode accesses. Except that the paging A/D bit setting is sort of
> different because it is physical address based (so I probably would
> better not have mentioned it above).
> 

You said "Accesses like the setting of a segment descriptor's accessed bit ...
also need to be done as if in supervisor mode". Considering implicit supervisor
mode accesses happen when CPL=3,do you mean the following scenario ?

Xen uses hvm_get_segment_register()/hvm_set_segment_register() to
access guest's segment registers while guest CPL=3.

> >> 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.
> >
> > I think we need to check CPL here. PFEC_user_mode clear only means
> > the fault happens on supervisor-mode accesses. But from Intel SDM
> > supervisor-mode accesses can occurs when CPL =3, please refer to:
> >
> > "Every access to a linear address is either a supervisor-mode access
> > or a user-mode access. All accesses performed while the current
> > privilege level (CPL) is less than 3 are supervisor-mode accesses.
> > If CPL = 3, accesses are generally user-mode accesses. However, some
> > operations implicitly access system data structures, and the resulting
> > accesses to those data structures are supervisor-mode accesses regardless
> > of CPL. Examples of such implicit supervisor accesses include the following:
> > accesses to the global descriptor table (GDT) or local descriptor table
> > (LDT) to load a segment descriptor; accesses to the interrupt descriptor
> > table (IDT) when delivering an interrupt or exception; and accesses to the
> > task-state segment (TSS) as part of a task switch or change of CPL."
> 
> Exactly. In other words, looking just at CPL is insufficient.
> 
> > Also, for SMAP hardware behaves differently between CPL=3 and CPL<3,
> >
> > " If CPL < 3, SMAP protections are disabled if EFLAGS.AC = 1. If CPL = 3,
> > SMAP applies to all supervisor-mode data accesses (these are implicit
> > supervisor accesses) regardless of the value of EFLAGS.AC."
> 
> Ah, right, I mis-read the combination of conditions. Which implies
> that in the spirit of this we mustn't bypass the CPL check by way
> of the flag suggested by Andrew (or else the hypervisor copy/clear
> operations wouldn't be treated as supervisor mode accesses in the
> sense above anymore).

I am a little confused now. The destination guest virtual address hypervisor 
will write to/read from
is always in a supervisor page, right? If this is the case, SMAP check is not 
needed since it is only used
for accesses to pages that are accessible in user mode.

In other words, is it possible for hypervisor to access a guest user page? If 
this can happen, I think
we should check CPL, since SMAP violation may occur during translating guest 
virtual address to
guest physical address.

Thanks,
Feng

> 
> Jan

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