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 9:22 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 15:15, <feng.wu@xxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> This being a PV extension to the base architecture, the hardware
> >> specification is meaningless. What we need to do here is _extend_ what
> >> the hardware has specified for those extra accesses. We have three
> >> options basically:
> >> 1) never do any checking on such accesses
> >> 2) honor CPL and EFLAGS.AC
> >> 3) always do the checking
> >> The first one obviously is bad from a security POV. Since the third one is
> >> more strict than the second and since I assume adding some override is
> >> going to be the simpler change than altering the point in time when the
> >> VMCS gets loaded during context switch (the suggestion of which no one
> >> at all commented on so far), I'd prefer that one, but wouldn't mind
> >> option 2 to be implemented instead.
> >>
> >
> > So here is my understanding for this:
> > For option 2, we don't need to change the code in guest_walk_tables(), what
> > we
> > should do is to adjust the time when VMCS gets loaded to make sure we can
> > safely get guest SS for the two cases you mentioned previously in this
> > thread.
> >
> > For option 3, we need to pass some override for these cases to check SMAP
> > unconditionally, so no need to get guest SS. Hence this issue will not
> > exist.
> >
> > Is this correct? Thanks a lot!
> 
> That's my understanding, so I hope it is correct.

After thinking a little more about what you said in this thread, here is the 
basic ideas
I get about this PV extension:
1. With this PV extension, when Xen tries to access guest memory for 
non-emulation
purpose, we always treat this access as a supervisor mode.

2. We need always do SMAP checking for those Xen accesses when SMAP is enabled 
by
the HVM guests. However, if the guest is actually running in Ring 0 and 
X86_EFLAGS_AC
bit is set by it, if we got an SMAP violation while doing the SMAP check, is 
this overkilled?

Thanks,
Feng

> 
> Jan


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