Re: [Xen-devel] [PATCH] x86: defer not-present segment checks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.10.16 at 14:28, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 06/10/16 13:24, Jan Beulich wrote:
>> Following on from commits 5602e74c60 ("x86emul: correct loading of
>> %ss") and bdb860d01c ("x86/HVM: correct segment register loading during
>> task switch") the point of the non-.present checks needs to be refined:
>> #NP (and its #SS companion), other than suggested by the various
>> instruction pages in Intel's SDM, gets checked for only after all type
>> and permission checks. The only checks getting done even later are the
>> 64-bit specific ones for system descriptors (which we don't support
>> yet).
> 
> Is this from observation on native hardware?

Yes. I also found that old paper manuals are more helpful in this
respect than the SDM is nowadays.

> The AMD manual does describe:
> 
> Present (P) Bit. Bit 15 of the upper doubleword. The segment-present bit
> indicates that the segment referenced by the descriptor is loaded in
> memory. If a reference is made to a descriptor entry when P = 0, a
> segment-not-present exception (#NP) occurs.
> 
> which doesn't imply that the present bit is a validity bit for the other
> contents of the segment.
> 
> Intel is similar, with:
> 
> Indicates whether the segment is present in memory (set) or not present
> (clear). If this flag is clear, the processor generates a
> segment-not-present exception (#NP) when a segment selector that points
> to the segment descriptor is loaded into a segment register.
> 
> Furthermore, Figure 3-9 shows what a segment descriptor looks like with
> the present flag is clear.  This quite clearly states that the type, S,
> DPL and P fields all have meanings, but that all other fields are
> explicitly available for software use.
> 
> Therefore, it seems legitimate to consider type/dpl/S before P, but we
> must take extra special care not to look at any other fields until P is
> found to be set.

Exactly.

Also note how e.g. emulate_gate_op() looks at the P bit of the gate
only after having done other relevant checks. Having looked at this
again just now I realize, though, that the P bit clear on the code
segment descriptor wrongly raises #GP. As this gets fixed by the
rework patch using the generic insn decoder, I won't bother submitting
a separate fix for this though; I'll just add a note to that patch's
commit message.

Jan


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