Content      ..     47      48      49      50     ..

Intel 64 and IA-32 Architectures. Software Developer’s Manual (2026) - page 49

PROTECTION

Data-Segment Descriptor

31

24 23 22 2120 19

16 15 14 13 12 11

8

7

0

A

D

Type

Limit

Base 31:24

G

B

0

V

P

P

Base 23:16

4

19:16

L

L

1

0

E

W

A

31

16 15

0

Base Address 15:00

Segment Limit 15:00

0

Code-Segment Descriptor

31

24 23 22 2120 19

16 15 14 13 12 11

8

7

0

A

D

Type

Base 31:24

G

D

0

V

Limit

P

P

Base 23:16

4

19:16

L

L

1

1

C

R

A

31

16 15

0

Base Address 15:00

Segment Limit 15:00

0

System-Segment Descriptor

31

24 23 22 2120 19

16 15 14 13 12 11

8

7

0

D

Limit

Base 31:24

G

0

P

P

0

Type

Base 23:16

4

19:16

L

31

16 15

0

Base Address 15:00

Segment Limit 15:00

0

A

Accessed

E

Expansion Direction

AVL Available to Sys. Programmers

G

Granularity

B

Big

R

Readable

C

Conforming

LIMIT

Segment Limit

D

Default

W

Writable

DPL

Descriptor Privilege Level

P

Present

Reserved

Figure 6-1. Descriptor Fields Used for Protection

Many different styles of protection schemes can be implemented with these fields and flags. When the operating

system creates a descriptor, it places values in these fields and flags in keeping with the particular protection style

chosen for an operating system or executive. Application programs do not generally access or modify these fields

and flags.

The following sections describe how the processor uses these fields and flags to perform the various categories of

checks described in the introduction to this chapter.

6.2.1

Code-Segment Descriptor in 64-bit Mode

Code segments continue to exist in 64-bit mode even though, for address calculations, the segment base is treated

as zero. Some code-segment (CS) descriptor content (the base address and limit fields) is ignored; the remaining

fields function normally (except for the readable bit in the type field).

Code segment descriptors and selectors are needed in IA-32e mode to establish the processor’s operating mode

and execution privilege-level. The usage is as follows:

Vol. 3A

6-3

PROTECTION

• IA-32e mode uses a previously unused bit in the CS descriptor. Bit 53 is defined as the 64-bit (L) flag and is

used to select between 64-bit mode and compatibility mode when IA-32e mode is active (IA32_EFER.LMA = 1).

See Figure 6-2.

- If CS.L = 0 and IA-32e mode is active, the processor is running in compatibility mode. In this case, CS.D

selects the default size for data and addresses. If CS.D = 0, the default data and address size is 16 bits. If

CS.D = 1, the default data and address size is 32 bits.

- If CS.L = 1 and IA-32e mode is active, the only valid setting is CS.D = 0. This setting indicates a default

operand size of 32 bits and a default address size of 64 bits. The CS.L = 1 and CS.D = 1 bit combination is

reserved for future use and a #GP fault will be generated on an attempt to use a code segment with these

bits set in IA-32e mode.

• In IA-32e mode, the CS descriptor’s DPL is used for execution privilege checks (as in legacy 32-bit mode).

Code-Segment Descriptor

31

24 23 22 2120 19

16 15 14 13 12 11

8

7

0

A

D

Type

G

D

L

V

P

P

4

L

L

1

1

C

R

A

31

0

0

A

Accessed

AVL Available to Sys. Programmer’s

G

Granularity

C

Conforming

R

Readable

D

Default

P

Present

DPL

Descriptor Privilege Level

L

64-Bit Flag

Figure 6-2. Descriptor Fields with Flags used in IA-32e Mode

6.3

LIMIT CHECKING

The limit field of a segment descriptor prevents programs or procedures from addressing memory locations outside

the segment. The effective value of the limit depends on the setting of the G (granularity) flag (see Figure 6-1). For

data segments, the limit also depends on the E (expansion direction) flag and the B (default stack pointer size

and/or upper bound) flag. The E flag is one of the bits in the type field when the segment descriptor is for a data-

segment type.

When the G flag is clear (byte granularity), the effective limit is the value of the 20-bit limit field in the segment

descriptor. Here, the limit ranges from 0 to FFFFFH (1 MByte). When the G flag is set (4-KByte page granularity),

the processor scales the value in the limit field by a factor of 2¹² (4 KBytes). In this case, the effective limit ranges

from FFFH (4 KBytes) to FFFFFFFFH (4 GBytes). Note that when scaling is used (G flag is set), the lower 12 bits of

a segment offset (address) are not checked against the limit; for example, note that if the segment limit is 0,

offsets 0 through FFFH are still valid.

For all types of segments except expand-down data segments, the effective limit is the last address that is allowed

to be accessed in the segment, which is one less than the size, in bytes, of the segment. The processor causes a

general-protection exception (or, if the segment is SS, a stack-fault exception) any time an attempt is made to

access the following addresses in a segment:

• A byte at an offset greater than the effective limit

• A word at an offset greater than the (effective-limit - 1)

• A doubleword at an offset greater than the (effective-limit - 3)

• A quadword at an offset greater than the (effective-limit - 7)

6-4

Vol. 3A

PROTECTION

The center (reserved for the most privileged code, data, and stacks) is used for the segments containing the critical

software, usually the kernel of an operating system. Outer rings are used for less critical software. (Systems that

use only 2 of the 4 possible privilege levels should use levels 0 and 3.)

Protection Rings

Operating

System

Kernel

Level 0

Operating System

Services

Level 1

Level 2

Applications

Level 3

Figure 6-3. Protection Rings

The processor uses privilege levels to prevent a program or task operating at a lesser privilege level from accessing

a segment with a greater privilege, except under controlled situations. When the processor detects a privilege level

violation, it generates a general-protection exception (#GP).

To carry out privilege-level checks between code segments and data segments, the processor recognizes the

following three types of privilege levels:

• Current privilege level (CPL) - The CPL is the privilege level of the currently executing program or task. It

is stored in bits 0 and 1 of the CS and SS segment registers. Normally, the CPL is equal to the privilege level of

the code segment from which instructions are being fetched. The processor changes the CPL when program

control is transferred to a code segment with a different privilege level. The CPL is treated slightly differently

when accessing conforming code segments. Conforming code segments can be accessed from any privilege

level that is equal to or numerically greater (less privileged) than the DPL of the conforming code segment.

Also, the CPL is not changed when the processor accesses a conforming code segment that has a different

privilege level than the CPL.

• Descriptor privilege level (DPL) - The DPL is the privilege level of a segment or gate. It is stored in the DPL

field of the segment or gate descriptor for the segment or gate. When the currently executing code segment

attempts to access a segment or gate, the DPL of the segment or gate is compared to the CPL and RPL of the

segment or gate selector (as described later in this section). The DPL is interpreted differently, depending on

the type of segment or gate being accessed:

- Data segment - The DPL indicates the numerically highest privilege level that a program or task can have

to be allowed to access the segment. For example, if the DPL of a data segment is 1, only programs running

at a CPL of 0 or 1 can access the segment.

- Nonconforming code segment (without using a call gate) - The DPL indicates the privilege level that

a program or task must be at to access the segment. For example, if the DPL of a nonconforming code

segment is 0, only programs running at a CPL of 0 can access the segment.

- Call gate - The DPL indicates the numerically highest privilege level that the currently executing program

or task can be at and still be able to access the call gate. (This is the same access rule as for a data

segment.)

- Conforming code segment and nonconforming code segment accessed through a call gate - The

DPL indicates the numerically lowest privilege level that a program or task can have to be allowed to access

the segment. For example, if the DPL of a conforming code segment is 2, programs running at a CPL of 0 or

1 cannot access the segment.

Vol. 3A

6-7

PROTECTION

- TSS - The DPL indicates the numerically highest privilege level that the currently executing program or

task can be at and still be able to access the TSS. (This is the same access rule as for a data segment.)

• Requested privilege level (RPL) - The RPL is an override privilege level that is assigned to segment

selectors. It is stored in bits 0 and 1 of the segment selector. The processor checks the RPL along with the CPL

to determine if access to a segment is allowed. Even if the program or task requesting access to a segment has

sufficient privilege to access the segment, access is denied if the RPL is not of sufficient privilege level. That is,

if the RPL of a segment selector is numerically greater than the CPL, the RPL overrides the CPL, and vice versa.

The RPL can be used to ensure that privileged code does not access a segment on behalf of an application

program unless the program itself has access privileges for that segment. See Section 6.10.4, “Checking Caller

Access Privileges (ARPL Instruction),” for a detailed description of the purpose and typical use of the RPL.

Privilege levels are checked when the segment selector of a segment descriptor is loaded into a segment register.

The checks used for data access differ from those used for transfers of program control among code segments;

therefore, the two kinds of accesses are considered separately in the following sections.

6.6

PRIVILEGE LEVEL CHECKING WHEN ACCESSING DATA SEGMENTS

To access operands in a data segment, the segment selector for the data segment must be loaded into the data-

segment registers (DS, ES, FS, or GS) or into the stack-segment register (SS). (Segment registers can be loaded

with the MOV, POP, LDS, LES, LFS, LGS, and LSS instructions.) Before the processor loads a segment selector into

a segment register, it performs a privilege check (see Figure 6-4) by comparing the privilege levels of the currently

running program or task (the CPL), the RPL of the segment selector, and the DPL of the segment’s segment

descriptor. The processor loads the segment selector into the segment register if the DPL is numerically greater

than or equal to both the CPL and the RPL. Otherwise, a general-protection fault is generated and the segment

register is not loaded.

CS Register

CPL

Segment Selector

For Data Segment

RPL

Privilege

Data-Segment Descriptor

Check

DPL

Figure 6-4. Privilege Check for Data Access

Figure 6-5 shows four procedures (located in codes segments A, B, C, and D), each running at different privilege

levels and each attempting to access the same data segment.

1. The procedure in code segment A is able to access data segment E using segment selector E1, because the CPL

of code segment A and the RPL of segment selector E1 are equal to the DPL of data segment E.

2. The procedure in code segment B is able to access data segment E using segment selector E2, because the CPL

of code segment B and the RPL of segment selector E2 are both numerically lower than (more privileged) than

the DPL of data segment E. A code segment B procedure can also access data segment E using segment

selector E1.

3. The procedure in code segment C is not able to access data segment E using segment selector E3 (dotted line),

because the CPL of code segment C and the RPL of segment selector E3 are both numerically greater than (less

privileged) than the DPL of data segment E. Even if a code segment C procedure were to use segment selector

6-8

Vol. 3A

PROTECTION

E1 or E2, such that the RPL would be acceptable, it still could not access data segment E because its CPL is not

privileged enough.

4. The procedure in code segment D should be able to access data segment E because code segment D’s CPL is

numerically less than the DPL of data segment E. However, the RPL of segment selector E3 (which the code

segment D procedure is using to access data segment E) is numerically greater than the DPL of data segment

E, so access is not allowed. If the code segment D procedure were to use segment selector E1 or E2 to access

the data segment, access would be allowed.

Code

Segment C

Segment Sel. E3

RPL=3

CPL=3

3

Lowest Privilege

Code

Segment Sel. E1

Data

Segment A

RPL=2

Segment E

CPL=2

2

DPL=2

Code

Segment Sel. E2

Segment B

RPL=1

CPL=1

1

Code

Segment D

CPL=0

Highest Privilege

0

Figure 6-5. Examples of Accessing Data Segments From Various Privilege Levels

As demonstrated in the previous examples, the addressable domain of a program or task varies as its CPL changes.

When the CPL is 0, data segments at all privilege levels are accessible; when the CPL is 1, only data segments at

privilege levels 1 through 3 are accessible; when the CPL is 3, only data segments at privilege level 3 are acces-

sible.

The RPL of a segment selector can always override the addressable domain of a program or task. When properly

used, RPLs can prevent problems caused by accidental (or intensional) use of segment selectors for privileged data

segments by less privileged programs or procedures.

It is important to note that the RPL of a segment selector for a data segment is under software control. For

example, an application program running at a CPL of 3 can set the RPL for a data- segment selector to 0. With the

RPL set to 0, only the CPL checks, not the RPL checks, will provide protection against deliberate, direct attempts to

violate privilege-level security for the data segment. To prevent these types of privilege-level-check violations, a

program or procedure can check access privileges whenever it receives a data-segment selector from another

procedure (see Section 6.10.4, “Checking Caller Access Privileges (ARPL Instruction)”).

6.6.1

Accessing Data in Code Segments

In some instances it may be desirable to access data structures that are contained in a code segment. The

following methods of accessing data in code segments are possible:

• Load a data-segment register with a segment selector for a nonconforming, readable, code segment.

• Load a data-segment register with a segment selector for a conforming, readable, code segment.

• Use a code-segment override prefix (CS) to read a readable, code segment whose selector is already loaded in

the CS register.

The same rules for accessing data segments apply to method 1. Method 2 is always valid because the privilege

level of a conforming code segment is effectively the same as the CPL, regardless of its DPL. Method 3 is always

valid because the DPL of the code segment selected by the CS register is the same as the CPL.

Vol. 3A

6-9

PROTECTION

CS Register

CPL

Segment Selector

For Code Segment

RPL

Destination Code

Privilege

Segment Descriptor

Check

DPL

C

Figure 6-6. Privilege Check for Control Transfer Without Using a Gate

• The DPL of the segment descriptor for the destination code segment that contains the called procedure.

• The RPL of the segment selector of the destination code segment.

• The conforming (C) flag in the segment descriptor for the destination code segment, which determines whether

the segment is a conforming (C flag is set) or nonconforming (C flag is clear) code segment. See Section

3.4.5.1, “Code- and Data-Segment Descriptor Types,” for more information about this flag.

The rules that the processor uses to check the CPL, RPL, and DPL depends on the setting of the C flag, as described

in the following sections.

6.8.1.1

Accessing Nonconforming Code Segments

When accessing nonconforming code segments, the CPL of the calling procedure must be equal to the DPL of the

destination code segment; otherwise, the processor generates a general-protection exception (#GP). For example

in Figure 6-7:

• Code segment C is a nonconforming code segment. A procedure in code segment A can call a procedure in code

segment C (using segment selector C1) because they are at the same privilege level (CPL of code segment A is

equal to the DPL of code segment C).

• A procedure in code segment B cannot call a procedure in code segment C (using segment selector C2 or C1)

because the two code segments are at different privilege levels.

Vol. 3A

6-11

PROTECTION

Segment Sel. D2

Code

RPL=3

Segment B

Segment Sel. C2

CPL=3

RPL=3

3

Lowest Privilege

Segment Sel. C1

Code

Code

RPL=2

Segment C

Segment A

Segment Sel. D1

DPL=2

CPL=2

RPL=2

Nonconforming

Code Segment

2

Code

Segment D

DPL=1

Conforming

1

Code Segment

Highest Privilege

0

Figure 6-7. Examples of Accessing Conforming and Nonconforming Code Segments From Various Privilege Levels

The RPL of the segment selector that points to a nonconforming code segment has a limited effect on the privilege

check. The RPL must be numerically less than or equal to the CPL of the calling procedure for a successful control

transfer to occur. So, in the example in Figure 6-7, the RPLs of segment selectors C1 and C2 could legally be set to

0, 1, or 2, but not to 3.

When the segment selector of a nonconforming code segment is loaded into the CS register, the privilege level field

is not changed; that is, it remains at the CPL (which is the privilege level of the calling procedure). This is true, even

if the RPL of the segment selector is different from the CPL.

6.8.1.2

Accessing Conforming Code Segments

When accessing conforming code segments, the CPL of the calling procedure may be numerically equal to or

greater than (less privileged) the DPL of the destination code segment; the processor generates a general-protec-

tion exception (#GP) only if the CPL is less than the DPL. (The segment selector RPL for the destination code

segment is not checked if the segment is a conforming code segment.)

In the example in Figure 6-7, code segment D is a conforming code segment. Therefore, calling procedures in both

code segment A and B can access code segment D (using either segment selector D1 or D2, respectively), because

they both have CPLs that are greater than or equal to the DPL of the conforming code segment. For conforming

code segments, the DPL represents the numerically lowest privilege level that a calling procedure may

be at to successfully make a call to the code segment.

(Note that segments selectors D1 and D2 are identical except for their respective RPLs. But since RPLs are not

checked when accessing conforming code segments, the two segment selectors are essentially interchangeable.)

When program control is transferred to a conforming code segment, the CPL does not change, even if the DPL of

the destination code segment is less than the CPL. This situation is the only one where the CPL may be different

from the DPL of the current code segment. Also, since the CPL does not change, no stack switch occurs.

Conforming segments are used for code modules such as math libraries and exception handlers, which support

applications but do not require access to protected system facilities. These modules are part of the operating

system or executive software, but they can be executed at numerically higher privilege levels (less privileged

levels). Keeping the CPL at the level of a calling code segment when switching to a conforming code segment

6-12

Vol. 3A

PROTECTION

prevents an application program from accessing nonconforming code segments while at the privilege level (DPL) of

a conforming code segment and thus prevents it from accessing more privileged data.

Most code segments are nonconforming. For these segments, program control can be transferred only to code

segments at the same level of privilege, unless the transfer is carried out through a call gate, as described in the

following sections.

6.8.2

Gate Descriptors

To provide controlled access to code segments with different privilege levels, the processor provides special set of

descriptors called gate descriptors. There are four kinds of gate descriptors:

• Call gates

• Trap gates

• Interrupt gates

• Task gates

Task gates are used for task switching and are discussed in Chapter 10, “Task Management.” Trap and interrupt

gates are special kinds of call gates used for calling exception and interrupt handlers. The are described in Chapter

7, “Interrupt and Exception Handling.” This chapter is concerned only with call gates.

6.8.3

Call Gates

Call gates facilitate controlled transfers of program control between different privilege levels. They are typically

used only in operating systems or executives that use the privilege-level protection mechanism. Call gates are also

useful for transferring program control between 16-bit and 32-bit code segments, as described in Section 24.4,

“Transferring Control Among Mixed-Size Code Segments.”

Figure 6-8 shows the format of a call-gate descriptor. A call-gate descriptor may reside in the GDT or in an LDT, but

not in the interrupt descriptor table (IDT). It performs six functions:

• It specifies the code segment to be accessed.

• It defines an entry point for a procedure in the specified code segment.

• It specifies the privilege level required for a caller trying to access the procedure.

31

16 15 14 13 12 11

8

7

6

5

4

0

D

Type

Param.

Offset in Segment 31:16

P

P

0

0

0

4

Count

L

0

1

1

0

0

31

16 15

0

Segment Selector

Offset in Segment 15:00

0

DPL

Descriptor Privilege Level

P

Gate Valid

Figure 6-8. Call-Gate Descriptor

• If a stack switch occurs, it specifies the number of optional parameters to be copied between stacks.

• It defines the size of values to be pushed onto the target stack: 16-bit gates force 16-bit pushes and 32-bit

gates force 32-bit pushes.

• It specifies whether the call-gate descriptor is valid.

The segment selector field in a call gate specifies the code segment to be accessed. The offset field specifies the

entry point in the code segment. This entry point is generally to the first instruction of a specific procedure. The DPL

field indicates the privilege level of the call gate, which in turn is the privilege level required to access the selected

Vol. 3A

6-13

PROTECTION

procedure through the gate. The P flag indicates whether the call-gate descriptor is valid. (The presence of the code

segment to which the gate points is indicated by the P flag in the code segment’s descriptor.) The parameter count

field indicates the number of parameters to copy from the calling procedures stack to the new stack if a stack

switch occurs (see Section 6.8.5, “Stack Switching”). The parameter count specifies the number of words for 16-

bit call gates and doublewords for 32-bit call gates.

Note that the P flag in a gate descriptor is normally always set to 1. If it is set to 0, a not present (#NP) exception

is generated when a program attempts to access the descriptor. The operating system can use the P flag for special

purposes. For example, it could be used to track the number of times the gate is used. Here, the P flag is initially

set to 0 causing a trap to the not-present exception handler. The exception handler then increments a counter and

sets the P flag to 1, so that on returning from the handler, the gate descriptor will be valid.

6.8.3.1

IA-32e Mode Call Gates

Call-gate descriptors in 32-bit mode provide a 32-bit offset for the instruction pointer (EIP); 64-bit extensions

double the size of 32-bit mode call gates in order to store 64-bit instruction pointers (RIP). See Figure 6-9:

• The first eight bytes (bytes 7:0) of a 64-bit mode call gate are similar but not identical to legacy 32-bit mode

call gates. The parameter-copy-count field has been removed.

• Bytes 11:8 hold the upper 32 bits of the target-segment offset in canonical form. A general-protection

exception (#GP) is generated if software attempts to use a call gate with a target offset that is not in canonical

form.

•

16-byte descriptors may reside in the same descriptor table with 16-bit and 32-bit descriptors. A type field,

used for consistency checking, is defined in bits 12:8 of the 64-bit descriptor’s highest dword (cleared to zero).

A general-protection exception (#GP) results if an attempt is made to access the upper half of a 64-bit mode

descriptor as a 32-bit mode descriptor.

31

13 12 11 10 9 8 7

0

Type

Reserved

Reserved

12

0

0

0

0

0

31

0

Offset in Segment 63:31

8

31

16 15 14 13 12 11

8

7

0

D

Type

Offset in Segment 31:16

P

P

0

4

L

0

1

1

0

0

31

16 15

0

Segment Selector

Offset in Segment 15:00

0

DPL

Descriptor Privilege Level

P

Gate Valid

Figure 6-9. Call-Gate Descriptor in IA-32e Mode

• Target code segments referenced by a 64-bit call gate must be 64-bit code segments (CS.L = 1, CS.D = 0). If

not, the reference generates a general-protection exception, #GP (CS selector).

• Only 64-bit mode call gates can be referenced in IA-32e mode (64-bit mode and compatibility mode). The

legacy 32-bit mode call gate type (0CH) is redefined in IA-32e mode as a 64-bit call-gate type; no 32-bit call-

gate type exists in IA-32e mode.

6-14

Vol. 3A

PROTECTION

• If a far call references a 16-bit call gate type (04H) in IA-32e mode, a general-protection exception (#GP) is

generated.

When a call references a 64-bit mode call gate, actions taken are identical to those taken in 32-bit mode, with the

following exceptions:

• Stack pushes are made in eight-byte increments.

• A 64-bit RIP is pushed onto the stack.

• Parameter copying is not performed.

Use a matching far-return instruction size for correct operation (returns from 64-bit calls must be performed with

a 64-bit operand-size return to process the stack correctly).

Call gates cannot be used when FRED transitions are enabled. An execution of CALL or JMP that accesses a call gate

when FRED transitions are enabled will cause a general-protection exception (#GP).

6.8.4

Accessing a Code Segment Through a Call Gate

To access a call gate, a far pointer to the gate is provided as a target operand in a CALL or JMP instruction. The

segment selector from this pointer identifies the call gate (see Figure 6-10); the offset from the pointer is required,

but not used or checked by the processor. (The offset can be set to any value.)

When the processor has accessed the call gate, it uses the segment selector from the call gate to locate the

segment descriptor for the destination code segment. (This segment descriptor can be in the GDT or the LDT.) It

then combines the base address from the code-segment descriptor with the offset from the call gate to form the

linear address of the procedure entry point in the code segment.

As shown in Figure 6-11, four different privilege levels are used to check the validity of a program control transfer

through a call gate:

• The CPL (current privilege level).

• The RPL (requestor privilege level) of the call gate’s selector.

• The DPL (descriptor privilege level) of the call gate descriptor.

• The DPL of the segment descriptor of the destination code segment.

The C flag (conforming) in the segment descriptor for the destination code segment is also checked.

Far Pointer to Call Gate

Segment Selector

Offset

Required but not used by processor

Descriptor Table

Offset

Call-Gate

Segment Selector

Offset

Descriptor

Base

Base

Code-Segment

Descriptor

Base

+

Procedure

Entry Point

Figure 6-10. Call-Gate Mechanism

Vol. 3A

6-15

PROTECTION

CS Register

CPL

Call-Gate Selector

RPL

Call Gate (Descriptor)

Privilege

Check

DPL

Destination Code-

Segment Descriptor

DPL

Figure 6-11. Privilege Check for Control Transfer with Call Gate

The privilege checking rules are different depending on whether the control transfer was initiated with a CALL or a

JMP instruction, as shown in Table 6-1.

Table 6-1. Privilege Check Rules for Call Gates

Instruction

Privilege Check Rules

CALL

CPL ≤ call gate DPL; RPL ≤ call gate DPL

Destination conforming code segment DPL ≤ CPL

Destination nonconforming code segment DPL ≤ CPL

JMP

CPL ≤ call gate DPL; RPL ≤ call gate DPL

Destination conforming code segment DPL ≤ CPL

Destination nonconforming code segment DPL = CPL

The DPL field of the call-gate descriptor specifies the numerically highest privilege level from which a calling proce-

dure can access the call gate; that is, to access a call gate, the CPL of a calling procedure must be equal to or less

than the DPL of the call gate. For example, in Figure 6-15, call gate A has a DPL of 3. So calling procedures at all

CPLs (0 through 3) can access this call gate, which includes calling procedures in code segments A, B, and C. Call

gate B has a DPL of 2, so only calling procedures at a CPL or 0, 1, or 2 can access call gate B, which includes calling

procedures in code segments B and C. The dotted line shows that a calling procedure in code segment A cannot

access call gate B.

The RPL of the segment selector to a call gate must satisfy the same test as the CPL of the calling procedure; that

is, the RPL must be less than or equal to the DPL of the call gate. In the example in Figure 6-15, a calling procedure

in code segment C can access call gate B using gate selector B2 or B1, but it could not use gate selector B3 to

access call gate B.

If the privilege checks between the calling procedure and call gate are successful, the processor then checks the

DPL of the code-segment descriptor against the CPL of the calling procedure. Here, the privilege check rules vary

between CALL and JMP instructions. Only CALL instructions can use call gates to transfer program control to more

privileged (numerically lower privilege level) nonconforming code segments; that is, to nonconforming code

segments with a DPL less than the CPL. A JMP instruction can use a call gate only to transfer program control to a

nonconforming code segment with a DPL equal to the CPL. CALL and JMP instruction can both transfer program

control to a more privileged conforming code segment; that is, to a conforming code segment with a DPL less than

or equal to the CPL.

6-16

Vol. 3A

PROTECTION

If a call is made to a more privileged (numerically lower privilege level) nonconforming destination code segment,

the CPL is lowered to the DPL of the destination code segment and a stack switch occurs (see Section 6.8.5, “Stack

Switching”). If a call or jump is made to a more privileged conforming destination code segment, the CPL is not

changed and no stack switch occurs.

Code

Gate Selector A

Call

Segment A

RPL=3

Gate A

CPL=3

Gate Selector B3

DPL=3

RPL=3

Lowest Privilege

3

Code

Call

Segment B

Gate Selector B1

Gate B

RPL=2

CPL=2

DPL=2

2

Code

Segment C

Gate Selector B2

RPL=1

CPL=1

No Stack

Stack Switch

1

Switch Occurs

Occurs

Code

Code

Segment D

Segment E

DPL=0

DPL=0

Conforming

Nonconforming

0

Highest Privilege

Code Segment

Code Segment

Figure 6-12. Example of Accessing Call Gates At Various Privilege Levels

Call gates allow a single code segment to have procedures that can be accessed at different privilege levels. For

example, an operating system located in a code segment may have some services which are intended to be used

by both the operating system and application software (such as procedures for handling character I/O). Call gates

for these procedures can be set up that allow access at all privilege levels (0 through 3). More privileged call gates

(with DPLs of 0 or 1) can then be set up for other operating system services that are intended to be used only by

the operating system (such as procedures that initialize device drivers).

6.8.5

Stack Switching

Whenever a call gate is used to transfer program control to a more privileged nonconforming code segment (that

is, when the DPL of the nonconforming destination code segment is less than the CPL), the processor automatically

switches to the stack for the destination code segment’s privilege level. This stack switching is carried out to

prevent more privileged procedures from crashing due to insufficient stack space. It also prevents less privileged

procedures from interfering (by accident or intent) with more privileged procedures through a shared stack.

Each task must define up to 4 stacks: one for applications code (running at privilege level 3) and one for each of

the privilege levels 2, 1, and 0 that are used. (If only two privilege levels are used [3 and 0], then only two stacks

must be defined.) Each of these stacks is located in a separate segment and is identified with a segment selector

and an offset into the stack segment (a stack pointer).

The segment selector and stack pointer for the privilege level 3 stack is located in the SS and ESP registers, respec-

tively, when privilege-level-3 code is being executed and is automatically stored on the called procedure’s stack

when a stack switch occurs.

Pointers to the privilege level 0, 1, and 2 stacks are stored in the TSS for the currently running task (see

Figure 10-2). Each of these pointers consists of a segment selector and a stack pointer (loaded into the ESP

register). These initial pointers are strictly read-only values. The processor does not change them while the task is

running. They are used only to create new stacks when calls are made to more privileged levels (numerically lower

Vol. 3A

6-17

PROTECTION

Calling Procedure’s Stack

Called Procedure’s Stack

Calling SS

Parameter 1

Calling ESP

Parameter 2

Parameter 1

Parameter 3

ESP

Parameter 2

Parameter 3

Calling CS

Calling EIP

ESP

Figure 6-13. Stack Switching During an Interprivilege-Level Call

The parameter count field in a call gate specifies the number of data items (up to 31) that the processor should

copy from the calling procedure’s stack to the stack of the called procedure. If more than 31 data items need to be

passed to the called procedure, one of the parameters can be a pointer to a data structure, or the saved contents

of the SS and ESP registers may be used to access parameters in the old stack space. The size of the data items

passed to the called procedure depends on the call gate size, as described in Section 6.8.3, “Call Gates.”

6.8.5.1

Stack Switching in 64-bit Mode

Although protection-check rules for call gates are unchanged from 32-bit mode, stack-switch changes in 64-bit

mode are different.

When stacks are switched as part of a 64-bit mode privilege-level change through a call gate, a new SS (stack

segment) descriptor is not loaded; 64-bit mode only loads an inner-level RSP from the TSS. The new SS is forced

to NULL and the SS selector’s RPL field is forced to the new CPL. The new SS is set to NULL in order to handle

nested far transfers (far CALL, INTn, interrupts, and exceptions). The old SS and RSP are saved on the new stack.

On a subsequent far RET, the old SS is popped from the stack and loaded into the SS register. See Table 6-2.

Table 6-2. 64-Bit-Mode Stack Layout After Far CALL with CPL Change

32-bit Mode

IA-32e mode

Old SS Selector

+12

+24

Old SS Selector

Old ESP

+8

+16

Old RSP

CS Selector

+4

+8

Old CS Selector

EIP

0

ESP

RSP

0

RIP

< 4 Bytes >

< 8 Bytes >

In 64-bit mode, stack operations resulting from a privilege-level-changing far call or far return are eight-bytes wide

and change the RSP by eight. The mode does not support the automatic parameter-copy feature found in 32-bit

mode. The call-gate count field is ignored. Software can access the old stack, if necessary, by referencing the old

stack-segment selector and stack pointer saved on the new process stack.

In 64-bit mode, far RET is allowed to load a NULL SS under certain conditions. If the target mode is 64-bit mode

and the target CPL ≠ 3, IRET allows SS to be loaded with a NULL selector. If the called procedure itself is inter-

rupted, the NULL SS is pushed on the stack frame. On the subsequent far RET, the NULL SS on the stack acts as a

flag to tell the processor not to load a new SS descriptor.

Vol. 3A

6-19

PROTECTION

63

32 31

0

Reserved

SYSCALL EFLAGS Mask

IA32_FMASK

63

0

Target RIP for 64-bit Mode Calling Program

IA32_LSTAR

63

48 47

32 31

0

SYSRET CS and SS

SYSCALL CS and SS

Reserved

IA32_STAR

Figure 6-14. MSRs Used by SYSCALL and SYSRET

The SYSCALL instruction does not save the stack pointer, and the SYSRET instruction does not restore it. It is likely

that the OS system-call handler will change the stack pointer from the user stack to the OS stack. If so, it is the

responsibility of software first to save the user stack pointer. This might be done by user code, prior to executing

SYSCALL, or by the OS system-call handler after SYSCALL.

Because the SYSRET instruction does not modify the stack pointer, it is necessary for software to switch back to the

user stack. The OS may load the user stack pointer (if it was saved after SYSCALL) before executing SYSRET; alter-

natively, user code may load the stack pointer (if it was saved before SYSCALL) after receiving control from

SYSRET.

If the OS loads the stack pointer before executing SYSRET, it must ensure that the handler of any interrupt or

exception delivered between restoring the stack pointer and successful execution of SYSRET is not invoked with the

user stack. It can do so using approaches such as the following:

• External interrupts. The OS can prevent an external interrupt from being delivered by clearing EFLAGS.IF

before loading the user stack pointer.

• Nonmaskable interrupts (NMIs). The OS can ensure that the NMI handler is invoked with the correct stack by

using the interrupt stack table (IST) mechanism for gate 2 (NMI) in the IDT (see Section 7.14.5, “Interrupt

Stack Table”).

• General-protection exceptions (#GP). The SYSRET instruction generates #GP(0) if the value of RCX is not

canonical. The OS can address this possibility using one or more of the following approaches:

- Confirming that the value of RCX is canonical before executing SYSRET.

- Using paging to ensure that the SYSCALL instruction will never save a non-canonical value into RCX.

- Using the IST mechanism for gate 13 (#GP) in the IDT.

When FRED transitions are enabled, SYSCALL and SYSENTER are implemented using FRED event delivery. SYSRET

and SYSEXIT are not used; instead, ERETU (or ERETS) are used to return. See Chapter 8, “Flexible Return and

Event Delivery (FRED).”

6.9

PRIVILEGED INSTRUCTIONS

Some of the system instructions (called “privileged instructions”) are protected from use by application programs.

The privileged instructions control system functions (such as the loading of system registers). They can be

Vol. 3A

6-23

PROTECTION

Passed as a

parameter on

the stack.

Application Program

Code

Call

Segment A

Gate Selector B

Segment Sel. D1

Gate B

RPL=3

RPL=3

CPL=3

DPL=3

Lowest Privilege

3

2

Access

not

allowed

1

Code

Data

Operating

Segment C

Segment Sel. D2 Segment D

System

RPL=0

DPL=0

DPL=0

Access

0

Highest Privilege

allowed

Figure 6-15. Use of RPL to Weaken Privilege Level of Called Procedure

Now assume that instead of setting the RPL of the segment selector to 3, the application program sets the RPL to

0 (segment selector D2). The operating system can now access data segment D, because its CPL and the RPL of

segment selector D2 are both equal to the DPL of data segment D.

Because the application program is able to change the RPL of a segment selector to any value, it can potentially use

a procedure operating at a numerically lower privilege level to access a protected data structure. This ability to

lower the RPL of a segment selector breaches the processor’s protection mechanism.

Because a called procedure cannot rely on the calling procedure to set the RPL correctly, operating-system proce-

dures (executing at numerically lower privilege-levels) that receive segment selectors from numerically higher

privilege-level procedures need to test the RPL of the segment selector to determine if it is at the appropriate level.

The ARPL (adjust requested privilege level) instruction is provided for this purpose. This instruction adjusts the RPL

of one segment selector to match that of another segment selector.

The example in Figure 6-15 demonstrates how the ARPL instruction is intended to be used. When the operating-

system receives segment selector D2 from the application program, it uses the ARPL instruction to compare the

RPL of the segment selector with the privilege level of the application program (represented by the code-segment

selector pushed onto the stack). If the RPL is less than application program’s privilege level, the ARPL instruction

changes the RPL of the segment selector to match the privilege level of the application program (segment selector

D1). Using this instruction thus prevents a procedure running at a numerically higher privilege level from

accessing numerically lower privilege-level (more privileged) segments by lowering the RPL of a segment selector.

Note that the privilege level of the application program can be determined by reading the RPL field of the segment

selector for the application-program’s code segment. This segment selector is stored on the stack as part of the call

to the operating system. The operating system can copy the segment selector from the stack into a register for

use as an operand for the ARPL instruction.

Vol. 3A

6-27

PROTECTION

Table 6-3. Combined Page-Directory and Page-Table Protection

User

Read-Only

User

Read-Only

User

Read-Only

User

Read-Only

User

Read-Write

User

Read-Only

User

Read-Write

User

Read-Only

User

Read-Only

User

Read-Write

User

Read-Write

User

Read/Write

User

Read-Only

Supervisor

Read-Only

Supervisor

Read/Write*

User

Read-Only

Supervisor

Read-Write

Supervisor

Read/Write*

User

Read-Write

Supervisor

Read-Only

Supervisor

Read/Write*

User

Read-Write

Supervisor

Read-Write

Supervisor

Read/Write

Supervisor

Read-Only

User

Read-Only

Supervisor

Read/Write*

Supervisor

Read-Only

User

Read-Write

Supervisor

Read/Write*

Supervisor

Read-Write

User

Read-Only

Supervisor

Read/Write*

Supervisor

Read-Write

User

Read-Write

Supervisor

Read/Write

Supervisor

Read-Only

Supervisor

Read-Only

Supervisor

Read/Write*

Supervisor

Read-Only

Supervisor

Read-Write

Supervisor

Read/Write*

Supervisor

Read-Write

Supervisor

Read-Only

Supervisor

Read/Write*

Supervisor

Read-Write

Supervisor

Read-Write

Supervisor

Read/Write

NOTE:

* If CR0.WP = 1, access type is determined by the R/W flags of the page-directory and page-table entries. IF CR0.WP = 0, supervisor

privilege permits read-write access.

6.13

PAGE-LEVEL PROTECTION AND EXECUTE-DISABLE BIT

In addition to page-level protection offered by the U/S and R/W flags, paging structures used with PAE paging, 4-

level paging,¹ and 5-level paging provide the execute-disable bit (see Chapter 5, “Paging”). This bit offers addi-

tional protection for data pages.

An Intel 64 or IA-32 processor with the execute-disable bit capability can prevent data pages from being used by

malicious software to execute code. This capability is provided in:

•

32-bit protected mode with PAE enabled.

• IA-32e mode.

While the execute-disable bit capability does not introduce new instructions, it does require operating systems to

use a PAE-enabled environment and establish a page-granular protection policy for memory pages.

If the execute-disable bit of a memory page is set, that page can be used only as data. An attempt to execute code

from a memory page with the execute-disable bit set causes a page-fault exception.

The execute-disable capability is not supported with 32-bit paging. Existing page-level protection mechanisms (see

Section 6.11, “Page-Level Protection”) continue to apply to memory pages independent of the execute-disable

setting.

6.13.1 Detecting and Enabling the Execute-Disable Capability

Software can detect the presence of the execute-disable capability using the CPUID instruction.

CPUID.80000001H:EDX.NX[20] = 1 indicates the capability is available.

1. Earlier versions of this manual used the term “IA-32e paging” to identify 4-level paging.

6-30

Vol. 3A

PROTECTION

If the capability is available, software can enable it by setting IA32_EFER.NXE[bit 11] to 1. IA32_EFER is available

if CPUID.80000001H:EDX[20 or 29] = 1.

If the execute-disable capability is not available, a write to set IA32_EFER.NXE produces a #GP exception. See

Table 6-4.

Table 6-4. Extended Feature Enable MSR (IA32_EFER)

63:12

11

10

9

8

7:1

0

Reserved

Execute-disable bit

IA-32e mode

Reserved

IA-32e mode

Reserved

SysCall enable (SCE)

enable (NXE)

active (LMA)

enable (LME)

6.13.2 Execute-Disable Page Protection

The execute-disable bit in the paging structures enhances page protection for data pages. Instructions cannot be

fetched from a memory page if IA32_EFER.NXE = 1 and the execute-disable bit is set in any of the paging-struc-

ture entries used to map the page. Table 6-5 lists the valid usage of a page in relation to the value of execute-

disable bit (bit 63) of the corresponding entry in each level of the paging structures. Execute-disable protection can

be activated using the execute-disable bit at any level of the paging structure, irrespective of the corresponding

entry in other levels. When execute-disable protection is not activated, the page can be used as code or data.

Vol. 3A

6-31

PROTECTION

Table 6-5. Page Level Protection Matrix with Execute-Disable Bit Capability with 4-Level Paging

Execute Disable Bit Value (Bit 63)

Valid Usage

PML4

PDP

PDE

PTE

Bit 63 = 1

*

*

*

Data

*

Bit 63 = 1

*

*

Data

*

*

Bit 63 = 1

*

Data

*

*

*

Bit 63 = 1

Data

Bit 63 = 0

Bit 63 = 0

Bit 63 = 0

Bit 63 = 0

Data/Code

NOTES:

* Value not checked.

In legacy PAE-enabled mode, Table 6-6 and Table 6-7 show the effect of setting the execute-disable bit for code and

data pages.

Table 6-6. 4-KByte Page Level Protection Matrix with Execute-Disable Bit Capability with PAE Paging

Execute Disable Bit Value (Bit 63)

Valid Usage

PDE

PTE

Bit 63 = 1

*

Data

*

Bit 63 = 1

Data

Bit 63 = 0

Bit 63 = 0

Data/Code

NOTE:

* Value not checked.

Table 6-7. 2-MByte Page Level Protection with Execute-Disable Bit Capability with PAE Paging

Execute Disable Bit Value (Bit 63)

Valid Usage

PDE

Bit 63 = 1

Data

Bit 63 = 0

Data/Code

6.13.3 Reserved Bit Checking

The processor enforces reserved bit checking in paging data structure entries. The bits being checked varies with

paging mode and may vary with the size of physical address space.

Table 6-8 shows the reserved bits that are checked when the execute disable bit capability is enabled (CR4.PAE = 1

and IA32_EFER.NXE = 1). Table 6-8 and Table 6-9 show the following paging modes:

• Non-PAE 4-KByte paging: 4-KByte-page only paging (CR4.PAE = 0, CR4.PSE = 0).

• PSE36: 4-KByte and 4-MByte pages (CR4.PAE = 0, CR4.PSE = 1).

• PAE: 4-KByte and 2-MByte pages (CR4.PAE = 1).

6-32

Vol. 3A

PROTECTION

Table 6-8. Page Level Protection Matrix with Execute-Disable Bit Capability Enabled

Mode

Paging Mode

Check Bits

32-bit

4-KByte paging (non-PAE)

No reserved bits checked

PSE36 - PDE, 4-MByte page

Bit 21

PSE36 - PDE, 4-KByte page

No reserved bits checked

PSE36 - PTE

No reserved bits checked

PAE - PDP table entry

Bits 63:MAXPHYADDR, 8:5, and 2:1

PAE - PDE, 2-MByte page

Bits 62:MAXPHYADDR and 20:13

PAE - PDE, 4-KByte page

Bits 62:MAXPHYADDR

PAE - PTE

Bits 62:MAXPHYADDR

64-bit

PML5E

Bits 51:MAXPHYADDR

PML4E

Bits 51:MAXPHYADDR

PDPTE

Bits 51:MAXPHYADDR

PDE, 2-MByte page

Bits 51:MAXPHYADDR and 20:13

PDE, 4-KByte page

Bits 51:MAXPHYADDR

PTE

Bits 51:MAXPHYADDR

The reserved bit checking depends on the physical-address width supported by the processor. This width is denoted

MAXPHYADDR and is enumerated in CPUID.80000008H:EAX[7:0].¹

If execute disable bit capability is not enabled or not available, reserved bit checking in 64-bit mode includes bit 63

and additional bits. This and reserved bit checking for legacy 32-bit paging modes are shown in Table 6-9.

Table 6-9. Reserved Bit Checking with Execute-Disable Bit Capability Not Enabled

Mode

Paging Mode

Check Bits

32-bit

KByte paging (non-PAE)

No reserved bits checked

PSE36 - PDE, 4-MByte page

Bit 21

PSE36 - PDE, 4-KByte page

No reserved bits checked

PSE36 - PTE

No reserved bits checked

PAE - PDP table entry

Bits 63:MAXPHYADDR, 8:5, and 2:1

PAE - PDE, 2-MByte page

Bits 63:MAXPHYADDR and 20:13

PAE - PDE, 4-KByte page

Bits 63:MAXPHYADDR

PAE - PTE

Bits 63:MAXPHYADDR

64-bit

PML5E

Bit 63, bits 51:MAXPHYADDR

PML4E

Bit 63, bits 51:MAXPHYADDR

PDPTE

Bit 63, bits 51:MAXPHYADDR

PDE, 2-MByte page

Bit 63, bits 51:MAXPHYADDR and 20:13

PDE, 4-KByte page

Bit 63, bits 51:MAXPHYADDR

PTE

Bit 63, bits 51:MAXPHYADDR

1. If IA32_TME_ACTIVATE[0] = 1 (indicating that TME has been configured), MAXPHYADDR is reduced by the value of IA32_TME_ACTI-

VATE[39:36] when a logical processor is outside secure arbitration mode (SEAM; see Chapter 35); the value is not reduced in SEAM.

Vol. 3A

6-33

INTERRUPT AND EXCEPTION HANDLING

Table 7-1 shows vector number assignments for architecturally defined exceptions and for the NMI interrupt. This

table gives the exception type (see Section 7.5, “Exception Classifications”) and indicates whether an error code is

saved on the stack for the exception. The source of each predefined exception and the NMI interrupt is also given.

7.3

SOURCES OF INTERRUPTS

The processor receives interrupts from two sources:

• External (hardware generated) interrupts.

• Software-generated interrupts.

7.3.1

External Interrupts

External interrupts are received through pins on the processor or through the local APIC. The primary interrupt pins

on Pentium 4, Intel Xeon, P6 family, and Pentium processors are the LINT[1:0] pins, which are connected to the

local APIC (see Chapter 13, “Advanced Programmable Interrupt Controller (APIC)”). When the local APIC is

enabled, the LINT[1:0] pins can be programmed through the APIC’s local vector table (LVT) to be associated with

any of the processor’s exception or interrupt vectors.

When the local APIC is global/hardware disabled, these pins are configured as INTR and NMI pins, respectively.

Asserting the INTR pin signals the processor that an external interrupt has occurred. The processor reads from the

system bus the interrupt vector number provided by an external interrupt controller, such as an 8259A (see Section

7.2, “Exception and Interrupt Vectors”). Asserting the NMI pin signals a non-maskable interrupt (NMI), which is

assigned to interrupt vector 2.

Table 7-1. Protected-Mode Exceptions and Interrupts

Vector

Mnemonic

Description

Type

Error

Source

Code

0

#DE

Divide Error

Fault

No

DIV and IDIV instructions.

1

#DB

Debug Exception

Fault/ Trap

No

Instruction, data, and I/O breakpoints;

single-step; and others.

2

-

NMI Interrupt

Interrupt

No

Nonmaskable external interrupt.

3

#BP

Breakpoint

Trap

No

INT3 instruction.

4

#OF

Overflow

Trap

No

INTO instruction.

5

#BR

BOUND Range Exceeded

Fault

No

BOUND instruction.

6

#UD

Invalid Opcode (Undefined Opcode)

Fault

No

UD instruction or reserved opcode.

7

#NM

Device Not Available (No Math

Fault

No

Floating-point or WAIT/FWAIT instruction.

Coprocessor)

8

#DF

Double Fault

Abort

Yes

Any instruction that can generate an

(zero)

exception, an NMI, or an INTR.

9

Coprocessor Segment Overrun

Fault

No

Floating-point instruction.¹

(reserved)

10

#TS

Invalid TSS

Fault

Yes

Task switch or TSS access.

11

#NP

Segment Not Present

Fault

Yes

Loading segment registers or accessing

system segments.

12

#SS

Stack-Segment Fault

Fault

Yes

Stack operations and SS register loads.

13

#GP

General Protection

Fault

Yes

Any memory reference and other

protection checks.

14

#PF

Page Fault

Fault

Yes

Any memory reference.

7-2

Vol. 3A

INTERRUPT AND EXCEPTION HANDLING

Table 7-1. Protected-Mode Exceptions and Interrupts (Contd.)

Vector

Mnemonic

Description

Type

Error

Source

Code

15

-

(Intel reserved. Do not use.)

No

16

#MF

x87 FPU Floating-Point Error (Math

Fault

No

x87 FPU floating-point or WAIT/FWAIT

Fault)

instruction.

17

#AC

Alignment Check

Fault

Yes

Any data reference in memory.²

18

#MC

Machine Check

Abort

No

Error codes (if any) and source are model

dependent.³

19

#XM

SIMD Floating-Point Exception

Fault

No

SSE/SSE2/SSE3 floating-point

instructions⁴

20

#VE

Virtualization Exception

Fault

No

EPT violations⁵

21

#CP

Control Protection Exception

Fault

Yes

RET, IRET, RSTORSSP, and SETSSBSY

instructions can generate this exception.

When CET indirect branch tracking is

enabled, this exception can be generated

due to a missing ENDBRANCH instruction

at target of an indirect call or jump.

22-31

-

Intel reserved. Do not use.

32-255

-

User Defined (Non-reserved)

Interrupt

External interrupt or INT n instruction.

Interrupts

NOTES:

1. Processors after the Intel386 processor do not generate this exception.

2. This exception was introduced in the Intel486 processor.

3. This exception was introduced in the Pentium processor and enhanced in the P6 family processors.

4. This exception was introduced in the Pentium III processor.

5. This exception can occur only on processors that support the 1-setting of the “EPT-violation #VE” VM-execution control.

The processor’s local APIC is normally connected to a system-based I/O APIC. Here, external interrupts received at

the I/O APIC’s pins can be directed to the local APIC through the system bus (Pentium 4, Intel Core Duo, Intel Core

2, Intel Atom, and Intel Xeon processors) or the APIC serial bus (P6 family and Pentium processors). The I/O APIC

determines the vector number of the interrupt and sends this number to the local APIC. When a system contains

multiple processors, processors can also send interrupts to one another by means of the system bus (Pentium 4,

Intel Core Duo, Intel Core 2, Intel Atom, and Intel Xeon processors) or the APIC serial bus (P6 family and Pentium

processors).

The LINT[1:0] pins are not available on the Intel486 processor and earlier Pentium processors that do not contain

an on-chip local APIC. These processors have dedicated NMI and INTR pins. With these processors, external inter-

rupts are typically generated by a system-based interrupt controller (8259A), with the interrupts being signaled

through the INTR pin.

Note that several other pins on the processor can cause a processor interrupt to occur. However, these interrupts

are not handled by the interrupt and exception mechanism described in this chapter. These pins include the

RESET#, FLUSH#, STPCLK#, SMI#, R/S#, and INIT# pins. Whether they are included on a particular processor is

implementation dependent. Pin functions are described in the data books for the individual processors. The SMI#

pin is described in Chapter 34, “System Management Mode.”

7.3.2

Maskable Hardware Interrupts

Any external interrupt that is delivered to the processor by means of the INTR pin or through the local APIC is called

a maskable hardware interrupt. Maskable hardware interrupts that can be delivered through the INTR pin include

all IA-32 architecture defined interrupt vectors from 0 through 255; those that can be delivered through the local

APIC include interrupt vectors 16 through 255.

Vol. 3A

7-3

INTERRUPT AND EXCEPTION HANDLING

• Any data breakpoint on the MOV to SS instruction or POP to SS instruction is inhibited until the instruction

boundary following the next instruction.

• Any single-step trap that would be delivered following the MOV to SS instruction or POP to SS instruction

(because EFLAGS.TF is 1) is suppressed.

• The suppression and inhibition ends after delivery of an exception or the execution of the next instruction.

• If a sequence of consecutive instructions each loads the SS register (using MOV or POP), only the first is

guaranteed to inhibit or suppress events in this way.

Intel recommends that software use the LSS instruction to load the SS register and ESP together. The problem

identified earlier does not apply to LSS, and the LSS instruction does not inhibit events as detailed above.

7.9

PRIORITIZATION OF CONCURRENT EVENTS

If more than one event is pending at an instruction boundary (between execution of instructions), the processor

services them in a predictable order. Table 7-2 shows the priority among classes of event sources.

Table 7-2. Priority Among Concurrent Events

Priority

Description

1 (Highest)

Hardware Reset and Machine Checks

- RESET

- Machine Check (#MC)

2

Trap on Task Switch

- T flag in TSS is set (#DB)

3

External Hardware Interventions

- FLUSH

- STOPCLK

- SMI

- INIT

4

Traps on the Previous Instruction

- Trap-class Debug Exceptions (#DB due to TF flag set or data/I-O breakpoint)

5

Nonmaskable Interrupts (NMI) ¹

6

Maskable Hardware Interrupts ¹

7

Fault-class Debug Exceptions (#DB due to instruction breakpoint)

8

Faults from Fetching Next Instruction

- Code-Segment Limit Violation (#GP)

- Code Page Fault (#PF)

9 (Lowest)

Faults from Decoding the Next Instruction

- Control protection exception due to missing ENDBRANCH at target of an indirect call or jump (#CP)

- Instruction length > 15 bytes (#GP)

- Invalid Opcode (#UD)

- Coprocessor Not Available (#NM)

NOTE

1. The Intel® 486 processor and earlier processors group nonmaskable and maskable interrupts in the same priority class.

The processor first services a pending event from the class which has the highest priority, transferring execution to

the first instruction of the handler. Lower priority exceptions are discarded; lower priority interrupts are held

pending. Discarded exceptions may be re-generated when the event handler returns execution to the point in the

program or task where the original event occurred. While the priority among the classes listed in Table 7-2 is

Vol. 3A

7-9

INTERRUPT AND EXCEPTION HANDLING

IDTR Register

47

16 15

0

IDT Base

Address

IDT Limit

Interrupt

Descriptor Table (IDT)

+

Gate for

Interrupt #n

(n-1)∗8

Gate for

Interrupt #3

16

Gate for

Interrupt #2

8

Gate for

Interrupt #1

0

31

0

Figure 7-1. Relationship of the IDTR and IDT

7.11

IDT DESCRIPTORS

NOTE

FRED event delivery does not use IDT descriptors. The material in this section does not apply when

FRED transitions are enabled. See Chapter 8, “Flexible Return and Event Delivery (FRED),” for more

information about FRED transitions.

The IDT may contain any of three kinds of gate descriptors:

• Task-gate descriptor

• Interrupt-gate descriptor

• Trap-gate descriptor

Figure 7-2 shows the formats for the task-gate, interrupt-gate, and trap-gate descriptors. The format of a task

gate used in an IDT is the same as that of a task gate used in the GDT or an LDT (see Section 10.2.5, “Task-Gate

Descriptor”). The task gate contains the segment selector for a TSS for an exception and/or interrupt handler task.

Interrupt and trap gates are very similar to call gates (see Section 6.8.3, “Call Gates”). They contain a far pointer

(segment selector and offset) that the processor uses to transfer program execution to a handler procedure in an

exception- or interrupt-handler code segment. These gates differ in the way the processor handles the IF flag in the

EFLAGS register (see Section 7.12.1.3, “Flag Usage By Exception- or Interrupt-Handler Procedure”).

Vol. 3A

7-11

INTERRUPT AND EXCEPTION HANDLING

Task Gate

31

16 15 14 13 12

8

7

0

D

P

P

0

0

1

0

1

4

L

31

16 15

0

TSS Segment Selector

0

Interrupt Gate

31

16 15 14 13 12

8

7

5

4

0

D

Offset 31..16

P

P

0

D 1

1

0

0

0

0

4

L

31

16 15

0

Segment Selector

Offset 15..0

0

Trap Gate

31

16 15 14 13 12

8

7

5

4

0

D

Offset 31..16

P

P

0

D 1

1

1

0

0

0

4

L

31

16 15

0

Segment Selector

Offset 15..0

0

DPL

Descriptor Privilege Level

Offset

Offset to procedure entry point

P

Segment Present flag

Selector

Segment Selector for destination code segment

D

Size of gate: 1 = 32 bits; 0 = 16 bits

Reserved

Figure 7-2. IDT Gate Descriptors

7.12

EXCEPTION AND INTERRUPT HANDLING

NOTE

This section focuses on event handling based on IDT event delivery and on return using the IRET

instruction. FRED transitions are alternatives to these mechanisms. In general, the material in this

section does not apply when FRED transitions are enabled. See Chapter 8, “Flexible Return and

Event Delivery (FRED),” for more information about FRED transitions.

The processor handles calls to exception- and interrupt-handlers similar to the way it handles calls with a CALL

instruction to a procedure or a task. When responding to an exception or interrupt, the processor uses the excep-

tion or interrupt vector as an index to a descriptor in the IDT. If the index points to an interrupt gate or trap gate,

the processor calls the exception or interrupt handler in a manner similar to a CALL to a call gate (see Section 6.8.2,

“Gate Descriptors,” through Section 6.8.6, “Returning from a Called Procedure”). If index points to a task gate, the

processor executes a task switch to the exception- or interrupt-handler task in a manner similar to a CALL to a task

gate (see Section 10.3, “Task Switching”).

7-12

Vol. 3A

INTERRUPT AND EXCEPTION HANDLING

7.12.1 Exception- or Interrupt-Handler Procedures

An interrupt gate or trap gate references an exception- or interrupt-handler procedure that runs in the context of

the currently executing task (see Figure 7-3). The segment selector for the gate points to a segment descriptor for

an executable code segment in either the GDT or the current LDT. The offset field of the gate descriptor points to

the beginning of the exception- or interrupt-handling procedure.

Destination

IDT

Code Segment

Interrupt

Offset

Procedure

Interrupt

Interrupt or

+

Vector

Trap Gate

Segment Selector

GDT or LDT

Base

Address

Segment

Descriptor

Figure 7-3. Interrupt Procedure Call

Vol. 3A

7-13

INTERRUPT AND EXCEPTION HANDLING

When the processor performs a call to the exception- or interrupt-handler procedure:

•

If the handler procedure is going to be executed at a numerically lower privilege level, a stack switch occurs.

When the stack switch occurs:

a. The segment selector and stack pointer for the stack to be used by the handler are obtained from the TSS

for the currently executing task. On this new stack, the processor pushes the stack segment selector and

stack pointer of the interrupted procedure.

b. The processor then saves the current state of the EFLAGS, CS, and EIP registers on the new stack (see

Figure 7-4).

c. If an exception causes an error code to be saved, it is pushed on the new stack after the EIP value.

•

If the handler procedure is going to be executed at the same privilege level as the interrupted procedure:

a. The processor saves the current state of the EFLAGS, CS, and EIP registers on the current stack (see Figure

7-4).

b. If an exception causes an error code to be saved, it is pushed on the current stack after the EIP value.

Stack Usage with No

Privilege-Level Change

Interrupted Procedure’s

and Handler’s Stack

ESP Before

EFLAGS

Transfer to Handler

CS

EIP

Error Code

ESP After

Transfer to Handler

Stack Usage with

Privilege-Level Change

Interrupted Procedure’s

Handler’s Stack

Stack

ESP Before

Transfer to Handler

SS

ESP

EFLAGS

CS

EIP

ESP After

Error Code

Transfer to Handler

Figure 7-4. Stack Usage on Transfers to Interrupt and Exception-Handling Routines

To return from an exception- or interrupt-handler procedure, the handler must use the IRET (or IRETD) instruction.

The IRET instruction is similar to the RET instruction except that it restores the saved flags into the EFLAGS

register. The IOPL field of the EFLAGS register is restored only if the CPL is 0. The IF flag is changed only if the CPL

is less than or equal to the IOPL. See Chapter 3, “Instruction Set Reference, A-L,” of the Intel^® 64 and IA-32 Archi-

tectures Software Developer’s Manual, Volume 2A, for a description of the complete operation performed by the

IRET instruction.

If a stack switch occurred when calling the handler procedure, the IRET instruction switches back to the interrupted

procedure’s stack on the return.

7-14

Vol. 3A

INTERRUPT AND EXCEPTION HANDLING

Shadow Stack Usage with

No Privilege-Level Change

Interrupted Procedure’s

and Handler’s Shadow Stack

SSP Before

Transfer to Handler

CS

LIP

SSP

SSP After

Transfer to Handler

Shadow Stack Usage with Privilege-

Level Change from Level 3

Interrupted Procedure’s

Handler’s Shadow Stack

Shadow Stack

SSP Before

Transfer to Handler

Supervisor

Shadow Stack

SSP After

Token

Transfer to Handler

Shadow Stack Usage with Privilege-

Level Change from Level 2 or 1

Interrupted Procedure’s

Handler’s Shadow Stack

Shadow Stack

SSP Before

Transfer to Handler

Supervisor

Shadow Stack

Token

CS

LIP

SSP After

SSP

Transfer to Handler

Figure 7-5. Shadow Stack Usage on Transfers to Interrupt and Exception-Handling Routines

To return from an exception- or interrupt-handler procedure, the handler must use the IRET (or IRETD) instruction.

When executing a return from an interrupt or exception handler from the same privilege level as the interrupted

procedure, the processor performs these actions to enforce return address protection:

• Restores the CS and EIP registers to their values prior to the interrupt or exception.

7-16

Vol. 3A

INTERRUPT AND EXCEPTION HANDLING

NOTE

Because IA-32 architecture tasks are not re-entrant, an interrupt-handler task must disable

interrupts between the time it completes handling the interrupt and the time it executes the IRET

instruction. This action prevents another interrupt from occurring while the interrupt task’s TSS is

still marked busy, which would cause a general-protection (#GP) exception.

TSS for Interrupt-

IDT

Handling Task

Interrupt

Task Gate

Vector

TSS Selector

TSS

Base

Address

GDT

TSS Descriptor

Figure 7-6. Interrupt Task Switch

7.13

ERROR CODE

When an exception condition is related to a specific segment selector or IDT vector, the processor pushes an error

code onto the stack of the exception handler (whether it is a procedure or task). The error code has the format

shown in Figure 7-7. The error code resembles a segment selector; however, instead of a TI flag and RPL field, the

error code contains 3 flags:

EXT

External event (bit 0) - When set, indicates that the exception occurred during delivery of an

event external to the program, such as an interrupt or an earlier exception.¹ The bit is cleared if the

exception occurred during delivery of a software interrupt (INT n, INT3, or INTO).

IDT

Descriptor location (bit 1) - When set, indicates that the index portion of the error code refers

to a gate descriptor in the IDT; when clear, indicates that the index refers to a descriptor in the GDT

or the current LDT. The processor does not set this bit when FRED transitions are enabled.

TI

GDT/LDT (bit 2) - Only used when the IDT flag is clear. When set, the TI flag indicates that the

index portion of the error code refers to a segment or gate descriptor in the LDT; when clear, it indi-

cates that the index refers to a descriptor in the current GDT.

1. The bit is also set if the exception occurred during delivery of INT1.

Vol. 3A

7-19

INTERRUPT AND EXCEPTION HANDLING

31

3

2

1

0

I

E

T

Reserved

Segment Selector Index

I

D

X

T

T

Figure 7-7. Error Code

The segment selector index field provides an index into the IDT, GDT, or current LDT to the segment or gate

selector being referenced by the error code. In some cases the error code is null (all bits are clear except possibly

EXT). A null error code indicates that the error was not caused by a reference to a specific segment or that a null

segment selector was referenced in an operation.

The format of the error code is different for page-fault exceptions (#PF). See the “Event 14-Page-Fault Exception

(#PF)” section in this chapter.

The format of the error code is different for control protection exceptions (#CP). See the “Event 21-Control

Protection Exception (#CP)” section in this chapter.

The error code is pushed on the stack as a doubleword or word (depending on the default interrupt, trap, or task

gate size). To keep the stack aligned for doubleword pushes, the upper half of the error code is reserved. Note that

the error code is not popped when the IRET instruction is executed to return from an exception handler, so the

handler must remove the error code before executing a return.

Error codes are not pushed on the stack for exceptions that are generated externally (with the INTR or LINT[1:0]

pins) or the INT n instruction, even if an error code is normally produced for those exceptions.

7.14

EXCEPTION AND INTERRUPT HANDLING IN 64-BIT MODE

NOTE

This section focuses on event handling based on IDT event delivery and on return using the IRET

instruction. FRED transitions are alternatives to these mechanisms. In general, the material in this

section does not apply when FRED transitions are enabled. See Chapter 8, “Flexible Return and

Event Delivery (FRED),” for more information about FRED transitions.

In 64-bit mode, interrupt and exception handling is similar to what has been described for non-64-bit modes. The

following are the exceptions:

• All interrupt handlers pointed by the IDT are in 64-bit code (this does not apply to the SMI handler).

• The size of interrupt-stack pushes is fixed at 64 bits; and the processor uses 8-byte, zero extended stores.

• The stack pointer (SS:RSP) is pushed unconditionally on interrupts. In legacy modes, this push is conditional

and based on a change in current privilege level (CPL).

• The new SS is set to NULL if there is a change in CPL.

• IRET behavior changes.

• There is a new interrupt stack-switch mechanism and a new interrupt shadow stack-switch mechanism.

• The alignment of interrupt stack frame is different.

7.14.1

64-Bit Mode IDT

Interrupt and trap gates are 16 bytes in length to provide a 64-bit offset for the instruction pointer (RIP). The 64-

bit RIP referenced by interrupt-gate descriptors allows an interrupt service routine to be located anywhere in the

linear-address space. See Figure 7-8.

7-20

Vol. 3A

INTERRUPT AND EXCEPTION HANDLING

Interrupt/Trap Gate

31

0

Reserved

12

31

0

Offset 63..32

8

31

16 15 14 13 12

11

8

7

5

4

2

0

D

Offset 31..16

P

P

0

TYPE

0

0

0

0

0

IST

4

L

31

16 15

0

Segment Selector

Offset 15..0

0

DPL

Descriptor Privilege Level

Offset

Offset to procedure entry point

P

Segment Present flag

Selector

Segment Selector for destination code segment

IST

Interrupt Stack Table

Figure 7-8. 64-Bit IDT Gate Descriptors

In 64-bit mode, the IDT index is formed by scaling the interrupt vector by 16. The first eight bytes (bytes 7:0) of a

64-bit mode interrupt gate are similar but not identical to legacy 32-bit interrupt gates. The type field (bits 11:8 in

bytes 7:4) is described in Table 3-2. The Interrupt Stack Table (IST) field (bits 4:0 in bytes 7:4) is used by the stack

switching mechanisms described in Section 7.14.5, “Interrupt Stack Table.” Bytes 11:8 hold the upper 32 bits of

the target RIP (interrupt segment offset) in canonical form. A general-protection exception (#GP) is generated if

software attempts to reference an interrupt gate with a target RIP that is not in canonical form.

The target code segment referenced by the interrupt gate must be a 64-bit code segment (CS.L = 1, CS.D = 0). If

the target is not a 64-bit code segment, a general-protection exception (#GP) is generated with the IDT vector

number reported as the error code.

Only 64-bit interrupt and trap gates can be referenced in IA-32e mode (64-bit mode and compatibility mode).

Legacy 32-bit interrupt or trap gate types (0EH or 0FH) are redefined in IA-32e mode as 64-bit interrupt and trap

gate types. No 32-bit interrupt or trap gate type exists in IA-32e mode. If a reference is made to a 16-bit interrupt

or trap gate (06H or 07H), a general-protection exception (#GP(0)) is generated.

7.14.2

64-Bit Mode Stack Frame

In legacy mode, the size of an IDT entry (16 bits or 32 bits) determines the size of interrupt-stack-frame pushes.

SS:ESP is pushed only on a CPL change. In 64-bit mode, the size of interrupt stack-frame pushes is fixed at eight

bytes. This is because only 64-bit mode gates can be referenced. 64-bit mode also pushes SS:RSP unconditionally,

rather than only on a CPL change.

When shadow stacks are enabled at the interrupt handler’s privilege level and the interrupted procedure was not

executing at a privilege level 3, then the processor pushes the CS:LIP:SSP of the interrupted procedure on the

shadow stack of the interrupt handler (where LIP is the linear address of the return address).

Aside from error codes, pushing SS:RSP unconditionally presents operating systems with a consistent interrupt-

stackframe size across all interrupts. Interrupt service-routine entry points that handle interrupts generated by the

INTn instruction or external INTR# signal can push an additional error code place-holder to maintain consistency.

In legacy mode, the stack pointer may be at any alignment when an interrupt or exception causes a stack frame to

be pushed. This causes the stack frame and succeeding pushes done by an interrupt handler to be at arbitrary

alignments. In IA-32e mode, the RSP is aligned to a 16-byte boundary before pushing the stack frame. The stack

frame itself is aligned on a 16-byte boundary when the interrupt handler is called. The processor can arbitrarily

realign the new RSP on interrupts because the previous (possibly unaligned) RSP is unconditionally saved on the

newly aligned stack. The previous RSP will be automatically restored by a subsequent IRET.

Vol. 3A

7-21

INTERRUPT AND EXCEPTION HANDLING

Legacy Mode

Stack Usage with

IA-32e Mode

Privilege-Level Change

Handler’s Stack

Handler’s Stack

+20

SS

SS

+40

+16

ESP

RSP

+32

+12

EFLAGS

RFLAGS

+24

+8

+16

CS

CS

+4

EIP

RIP

+8

0

Error Code

Stack Pointer After

Error Code

0

Transfer to Handler

Figure 7-9. IA-32e Mode Stack Usage After Privilege Level Change

7.14.5 Interrupt Stack Table

In IA-32e mode, a new interrupt stack table (IST) mechanism is available as an alternative to the modified legacy

stack-switching mechanism described above. This mechanism unconditionally switches stacks when it is enabled.

It can be enabled on an individual interrupt-vector basis using a field in the IDT entry. This means that some inter-

rupt vectors can use the modified legacy mechanism and others can use the IST mechanism.

The IST mechanism is only available in IA-32e mode. It is part of the 64-bit mode TSS. The motivation for the IST

mechanism is to provide a method for specific interrupts (such as NMI, double-fault, and machine-check) to always

execute on a known good stack. In legacy mode, interrupts can use the task-switch mechanism to set up a known-

good stack by accessing the interrupt service routine through a task gate located in the IDT. However, the legacy

task-switch mechanism is not supported in IA-32e mode.

The IST mechanism provides up to seven IST pointers in the TSS. The pointers are referenced by an interrupt-gate

descriptor in the interrupt-descriptor table (IDT); see Figure 7-8. The gate descriptor contains a 3-bit IST index

field that provides an offset into the IST section of the TSS. Using the IST mechanism, the processor loads the

value pointed by an IST pointer into the RSP.

When an interrupt occurs, the new SS selector is forced to NULL and the SS selector’s RPL field is set to the new

CPL. The old SS, RSP, RFLAGS, CS, and RIP are pushed onto the new stack. Interrupt processing then proceeds as

normal. If the IST index is zero, the modified legacy stack-switching mechanism described above is used.

To support this stack-switching mechanism with shadow stacks enabled, the processor provides an MSR, IA32_IN-

TERRUPT_SSP_TABLE_ADDR, to program the linear address of a table of seven shadow stack pointers that are

selected using the IST index from the gate descriptor. To switch to a shadow stack selected from the interrupt

shadow stack table pointed to by the IA32_INTERRUPT_SSP_TABLE_ADDR, the processor requires that the

shadow stack addresses programmed into this table point to a supervisor shadow stack token; see Figure 7-10.

Vol. 3A

7-23

INTERRUPT AND EXCEPTION HANDLING

Figure 7-10. Interrupt Shadow Stack Table

7.15

EXCEPTION AND INTERRUPT REFERENCE

The following sections describe conditions which generate exceptions and interrupts. They are arranged in the

order of vector numbers. The information contained in these sections are as follows:

• Exception Class - Indicates whether the exception class is a fault, trap, or abort type. Some exceptions can

be either a fault or trap type, depending on when the error condition is detected. (This section is not applicable

to interrupts.)

• Description - Gives a general description of the purpose of the exception or interrupt type. It also describes

how the processor handles the exception or interrupt.

• Exception Error Code - Indicates whether an error code is saved for the exception. If one is saved, the

contents of the error code are described. (This section is not applicable to interrupts.)

• Event Data - In addition to the error code, FRED event delivery provides 64 bits of additional information for

certain events

• Saved Instruction Pointer - Describes which instruction the saved (or return) instruction pointer points to.

It also indicates whether the pointer can be used to restart a faulting instruction.

• Program State Change - Describes the effects of the exception or interrupt on the state of the currently

running program or task and the possibilities of restarting the program or task without loss of continuity.

7-24

Vol. 3A

INTERRUPT AND EXCEPTION HANDLING

Event 1-Debug Exception (#DB)

Exception Class

Trap or Fault. The exception handler can distinguish between traps or faults by exam-

ining the contents of DR6 and the other debug registers.

Description

Indicates that one or more of several debug-exception conditions has been detected. Whether the exception is a

fault or a trap depends on the condition (see Table 7-3). See Chapter 20, “Debug, Branch Profile, TSC, and Intel®

Resource Director Technology (Intel® RDT) Features,” for detailed information about the debug exceptions.

Table 7-3. Debug Exception Conditions and Corresponding Exception Classes

Exception Condition

Exception Class

Instruction fetch breakpoint

Fault

Data read or write breakpoint

Trap

I/O read or write breakpoint

Trap

General detect condition (in conjunction with in-circuit emulation)

Fault

Single-step

Trap

Task-switch

Trap

Execution of INT1¹

Trap

NOTES:

1. Hardware vendors may use the INT1 instruction for hardware debug. For that reason, Intel recommends software vendors instead

use the INT3 instruction for software breakpoints.

Exception Error Code

None. An exception handler can examine the debug registers (or, with FRED event delivery, the event data; see

below) to determine which condition caused the exception.

Event Data

FRED event delivery of a debug exception saves information that identifies the nature of the debug exception:

• Bits 3:0 are B3-B0. When set, each of these bits indicates that the corresponding breakpoint condition was met

(and may be set even if its corresponding enabling bit in DR7 is not set).

• Bits 10:4 are not currently defined and will be zero until they are.

• Bit 11 is BLD. When set, this bit indicates that the cause of the debug exception was acquisition of a bus lock

(because IA32_DEBUGCTL[2] = 1).

• Bit 12 is not currently defined and will be zero until it is.

• Bit 13 is BD. When set, this bit indicates that the cause of the debug exception was “debug register access

detected.”

• Bit 14 is BS. When set, this bit indicates that the cause of the debug exception was the execution of a single

instruction (because execution of that instruction commenced with RFLAGS.TF = 1).¹

• Bit 15 is not currently defined and will be zero until it is.

• Bit 16 is RTM. When set, this bit indicates that a debug exception (#DB) or a breakpoint exception (#BP)

occurred inside an RTM region while advanced debugging of RTM transactional regions was enabled.

• Bits 63:17 are not currently defined and will be zero until they are.

1. If in addition IA32_DEBUGCTL.BTF was 1 when the instruction commenced, a debug exception occurs only if the instruction was a

taken branch.

7-26

Vol. 3A

INTERRUPT AND EXCEPTION HANDLING

Event 8-Double Fault Exception (#DF)

Exception Class

Abort.

Description

Indicates that the processor detected a second exception while calling an exception handler for a prior exception.

Normally, when the processor detects another exception while trying to call an exception handler, the two excep-

tions can be handled serially. If, however, the processor cannot handle them serially, it signals the double-fault

exception. To determine when two faults need to be signalled as a double fault, the processor divides the excep-

tions into three classes: benign exceptions, contributory exceptions, and page faults (see Table 7-4).

Table 7-4. Interrupt and Exception Classes

Class

Vector Number

Description

Benign Exceptions and Interrupts

1

Debug

2

NMI Interrupt

3

Breakpoint

4

Overflow

5

BOUND Range Exceeded

6

Invalid Opcode

7

Device Not Available

9

Coprocessor Segment Overrun

16

Floating-Point Error

17

Alignment Check

18

Machine Check

19

SIMD floating-point

All

INT n

All

INTR

Contributory Exceptions

0

Divide Error

10

Invalid TSS

11

Segment Not Present

12

Stack Fault

13

General Protection

21

Control Protection

Page Faults

14

Page Fault

20

Virtualization Exception

Table 7-5 shows the various combinations of exception classes that cause a double fault to be generated. A double-

fault exception falls in the abort class of exceptions. The program or task cannot be restarted or resumed. The

double-fault handler can be used to collect diagnostic information about the state of the machine and/or, when

possible, to shut the application and/or system down gracefully or restart the system.

7-36

Vol. 3A

Content      ..     47      48      49      50     ..