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: Wednesday, July 02, 2014 3:50 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 02.07.14 at 09:32, <feng.wu@xxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> No, I mean the emulation of a selector register load operation, which
> >> needs to set the accessed bit in the referenced segment descriptor.
> >> But that's a different topic anyway, so let's focus on the issue at hand.
> >
> > Okay, one more question about this, I go through the relative code, seems
> > the accessed
> > bit in segment descriptor is not set when emulation of a selector register
> > load operation
> > by Xen, right?
> 
> Not sure where you're looking -
> xen/arch/x86/x86_emulate/x86_emulate.c:protmode_load_seg() does
> what is needed afaict.

Yes, I just also find this place, thanks a lot for this!

> 
> > For native case, when application code running in CPL=3 executes 'movl %eax,
> > %es',
> > it will trigger implicit supervisor mode accesses, since this operation will
> > also load
> > the segment descriptor to the hidden part of the segment register.
> >
> > What kind of implicitly supervisor mode accesses does Xen do? Since
> > implicitly
> > supervisor mode accesses only happens when CPL=3, the only way I can think
> > of now
> > is for emulation, like, Xen uses hvm_set_segment_register() to set guest's
> > segment
> > registers while guest CPL=3. But how should we check SMAP for this case? In
> > fact,
> > in native case, I don't think there will be SMAP violation for implicitly
> > supervisor mode accesses, since these data are mapped as supervisor pages.
> 
> No, you're again looking at the segment register load side, which isn't
> what this started with, and which we should put aside. The implicit
> supervisor mode accesses we're needing to deal with here are the
> ones _not_ resulting from emulation of anything: The update of the
> runstate area (which is what Sander stumbled across) and (similar)
> the update of time data, i.e. update_secondary_system_time(). Now
> that I think about it the two are actually different: The latter is
> specifically intended to update posibly user mode visible data, so we
> need to first determine whether it is correct to apply the SMAP check
> here (I think it is since the virtual address given to the kernel
> shouldn't be the one exposed to user mode - at least on Linux, so
> the question is whether we can assume eventual other OSes making
> use of this PV extension to also use distinct virtual addresses here).

If I understand it correctly, referring to the two examples you mentioned here, 
this is about a shared memory between Xen and guests. I have some questions 
about this:
1. What is the relationship between these operations and implicit supervisor 
mode accesses?
Seems this is not what is defined for implicit supervisor mode accesses in the 
Spec.
2. For the first case you mentioned above, (v)->runstate_guest is a guest 
pointer which
is set in 'VCPUOP_register_runstate_memory_area' operation, but I only see this 
pointer
is set for domain 0, how is it set for HVM guests? For Sander's case, seems 
this pointer
is set for the HVM guests (d1v0).

Here is a quote from Intel SDM:
"If CR4.SMAP=1, supervisor-mode data accesses are not allowed to linear 
addresses that are accessible in user mode",
So for the second case you listed above, if Xen and user space use different 
virtual
address, if the virtual address for Xen usage is supervisor-only, no SMAP check 
will
be needed, However, if they use the same virtual address, SMAP check may be 
needed
if this virtual address is use accessible. 

Thanks in advance for your clarification on this!

> 
> >> > 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.
> >>
> >> Correct. The question just is how to safely get at the guest's CPL, or
> >> how to override it (to, say, always imply user mode on non-emulation
> >> Xen accesses like the one here, i.e. to enforce the SMAP check
> >> regardless of guest CPL/EFLAGS.AC).
> >
> > So, in fact, the only thing need to do for this issue is find a way to get
> > the
> > guest's CPL, since the current way doesn't work fine because of the
> > scheduling.
> > We don't need to change the other logic in the code. Is my understanding
> > right?
> 
> Yes.
> 
> Jan


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