Vol. 3A 5-5
PROTECTION
•
A double quadword at an offset greater than the (effective limit – 15)
When the effective limit is FFFFFFFFH (4 GBytes), these accesses may or may not cause the indicated exceptions.
Behavior is implementation-specific and may vary from one execution to another.
For expand-down data segments, the segment limit has the same function but is interpreted differently. Here, the
effective limit specifies the last address that is not allowed to be accessed within the segment; the range of valid
offsets is from (effective-limit + 1) to FFFFFFFFH if the B flag is set and from (effective-limit + 1) to FFFFH if the B
flag is clear. An expand-down segment has maximum size when the segment limit is 0.
Limit checking catches programming errors such as runaway code, runaway subscripts, and invalid pointer calcu-
lations. These errors are detected when they occur, so identification of the cause is easier. Without limit checking,
these errors could overwrite code or data in another segment.
In addition to checking segment limits, the processor also checks descriptor table limits. The GDTR and IDTR regis-
ters contain 16-bit limit values that the processor uses to prevent programs from selecting a segment descriptors
outside the respective descriptor tables. The LDTR and task registers contain 32-bit segment limit value (read from
the segment descriptors for the current LDT and TSS, respectively). The processor uses these segment limits to
prevent accesses beyond the bounds of the current LDT and TSS. See Section 3.5.1, “Segment Descriptor Tables,”
for more information on the GDT and LDT limit fields; see Section 6.10, “Interrupt Descriptor Table (IDT),” for more
information on the IDT limit field; and see Section 7.2.4, “Task Register,” for more information on the TSS segment
limit field.
5.3.1
Limit Checking in 64-bit Mode
In 64-bit mode, the processor does not perform runtime limit checking on code or data segments. However, the
processor does check descriptor-table limits.
5.4 TYPE
CHECKING
Segment descriptors contain type information in two places:
•
The S (descriptor type) flag.
•
The type field.
The processor uses this information to detect programming errors that result in an attempt to use a segment or
gate in an incorrect or unintended manner.
The S flag indicates whether a descriptor is a system type or a code or data type. The type field provides 4 addi-
tional bits for use in defining various types of code, data, and system descriptors. Table 3-1 shows the encoding of
the type field for code and data descriptors; Table 3-2 shows the encoding of the field for system descriptors.
The processor examines type information at various times while operating on segment selectors and segment
descriptors. The following list gives examples of typical operations where type checking is performed (this list is not
exhaustive):
•
When a segment selector is loaded into a segment register — Certain segment registers can contain only
certain descriptor types, for example:
— The CS register only can be loaded with a selector for a code segment.
— Segment selectors for code segments that are not readable or for system segments cannot be loaded into
data-segment registers (DS, ES, FS, and GS).
— Only segment selectors of writable data segments can be loaded into the SS register.
•
When a segment selector is loaded into the LDTR or task register — For example:
— The LDTR can only be loaded with a selector for an LDT.
— The task register can only be loaded with a segment selector for a TSS.
•
When instructions access segments whose descriptors are already loaded into segment registers —
Certain segments can be used by instructions only in certain predefined ways, for example:
— No instruction may write into an executable segment.