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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?

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.

~Andrew

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