> The iretq instruction is the one and only way to return from exceptions and is specifically designed for this purpose.
Not quite true. STI; LRET works too, and it's faster for stupid reasons.
Also, the AMD architects blew it badly here. That quote from the manual:
> IRET “must be used to terminate the exception or interrupt handler associated with the exception”.
Indicates that the architects didn't think about how multitasking works. Consider:
1. User process A goes to sleep using a system call (select, nanosleep, whatever) that uses the SYSCALL instruction.
2. The kernel does a context switch to process B.
3. B's time slice runs out. The kernel finds out about this due to an interrupt. The kernel switches back to process A.
4. The kernel returns to process A's user code using SYSRET.
This is an entirely ordinary sequence of events. But think about it from the CPU's perspective: the CPU entered the kernel in step 3 via an interrupt and returned in step 4 using SYSRET, which is not the same thing as IRETQ. Oh no!
It turns out that this actually causes a problem on AMD CPUs: SYSRET will screw up the hidden part of the SS descriptor, causing bizarre crashes. Go AMD.
Intel, fortunately, implemented SYSRET a bit differently and it works fine. Linux has a specific workaround for this design failure -- search for SYSRET_SS_ATTRS in the kernel source. I don't know how other kernels deal with it.
Of course, Intel made other absurd errors in their IA-32e design , but that's another story.