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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

> 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).

>> > 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