Specification Update
21
Errata
BG10.
Fault on ENTER Instruction May Result in Unexpected Values on Stack Frame
Problem:
The ENTER instruction is used to create a procedure stack frame. Due to this erratum,
if execution of the ENTER instruction results in a fault, the dynamic storage area of the
resultant stack frame may contain unexpected values (i.e., residual stack data as a
result of processing the fault).
Implication: Data in the created stack frame may be altered following a fault on the ENTER
instruction. Refer to “Procedure Calls for Block-Structured Languages” in IA-32 Intel
®
Architecture Software Developer's Manual, Vol. 1, Basic Architecture, for information
on the usage of the ENTER instructions. This erratum is not expected to occur in Ring 3.
Faults are usually processed in Ring 0 and stack switch occurs when transferring to
Ring 0. Intel has not observed this erratum on any commercially-available software.
Workaround:None identified.
Status:
For the steppings affected, see the Summary Tables of Changes.
BG11.
IRET under Certain Conditions May Cause an Unexpected Alignment Check
Exception
Problem:
In IA-32e mode, it is possible to get an Alignment Check Exception (#AC) on the IRET
instruction even though alignment checks were disabled at the start of the IRET. This
can only occur if the IRET instruction is returning from CPL3 code to CPL3 code. IRETs
from CPL0/1/2 are not affected. This erratum can occur if the EFLAGS value on the
stack has the AC flag set, and the interrupt handler's stack is misaligned. In IA-32e
mode, RSP is aligned to a 16-byte boundary before pushing the stack frame.
Implication: In IA-32e mode, under the conditions given above, an IRET can get a #AC even if
alignment checks are disabled at the start of the IRET. This erratum can only be
observed with a software generated stack frame.
Workaround:Software should not generate misaligned stack frames for use with IRET.
Status:
For the steppings affected, see the Summary Tables of Changes.
