Re: [Xen-devel] [PATCH for 4.9 3/6] x86/hvm: Fix segmentation logic for system segments

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.04.17 at 12:18, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 03/04/17 18:37, Andrew Cooper wrote:
>>>> Without this fix, implicit accesses to system segments in a
>>>> compatibility mode segment will truncate the resulting linear address as
>>>> part of performing the segmentation calculations, which is obviously not
>>>> how real hardware behaves.
>>> I understand this. But things are a little more complicated. Just
>>> extend your line of thinking regarding IDTR/GDTR to LDTR and
>>> TR: Above you suggest that the former two get loaded in a fully
>>> 32-bit mode compatible way. LTR and LLDT (as well as LAR and
>>> LSL), however, access a descriptor table. 32-bit code would
>>> expect an 8-byte descriptor to be read. Is compat mode code
>>> then not allowed to make the same assumption?
>> Hmm - the wording of LTR/LLDT in both manuals states 64bit mode, not
>> long mode, so there is a decent chance that the compat behaviour is
>> identical.  Let me experiment.
> 
> In a compat mode segment, lldt/ltr operates almost identically to
> protected mode.  They read 8-byte entries, and zero extends the base
> field when loading the result into the segment cache.  However, in
> compatibility mode, they are still subject to long mode restrictions. 
> In particular, you can't attempt to load a 16bit TSS while in a compat
> mode segment.

Interesting, and sort of unexpected. Besides this likely meaning we
need to further adjust the emulator, this raises a question on call
gates then: What factor is it which determines whether a call gate
is an 8- or 16-byte one? Is this perhaps dependent on the L bit of
the code segment descriptor referred to by the gate's code selector?

Jan


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