14

I was just reading What is linux-gate.so.1?, and it says this:

Intel recognized this problem early on and introduced a more efficient system call interface in the form of sysenter and sysexit instructions. This fast system call feature first appeared in the Pentium Pro processor, but due to hardware bugs it's actually broken in most of the early CPUs

I did some research and it seems as if SYSENTER was not documented until the Pentium II, and further, this bug that stopped its adoption until much later is hinted at again:

It seems likely that Intel discovered some problem with the SYSENTER instruction very shortly before the chip was released. And instead of documenting the problems and fixing them, Intel decided not to document the instruction at all.

The comments on the latter article suggest that the issue might lie in SYSEXIT rather than SYSENTER. What specific defects in the Pentium Pro and early Pentium II make it impossible to use SYSENTER as intended?

Improve this question
0

1 Answer 1

Reset to default
10

In the Pentium® II Processor Specification Update Release Date: October 1998 errata for the Intel documentation, the entry for A62 states:

Plans - Errata

NoFix - SYSENTER/SYSEXIT instructions can implicitly load “null segment selector” to SS and CS registers

SYSENTER would set wrong selectors, but that was okay, because you were still in kernel memory, but as soon as you tried to go back (via SYSEXIT), you would double-fault and crash the system. Linux users that experienced this problem would get SIGSEGV faults on kernel load, and had to either patch their kernel or roll back until an official patch was put out.

In theory, a kernel that was aware of the problem might have been able to work around it, but I couldn't find any specific kernel source or documentation for an OS that used some other means of returning to ring 3 without crashing. SYSENTER/SYSEXIT was only meant as a performance boost over INT/IRET for calling the OS, so there really wasn't a reason to work around it for the potential performance gains.

Improve this answer
3
  • 2
    That doesn’t explain why Intel would tell developers to avoid the instruction entirely though, since the null descriptors can be worked around. See the linked OS/2 Museum discussion which mentions this erratum.
    – Stephen Kitt
    Oct 5, 2018 at 4:31
  • 6
    @StephenKitt When you document a feature, that means that you're subject to supporting it. If it's not documented, and someone uses it, you can legally defend yourself saying that "we never told them to use it, so it was improper use of the hardware." Basically, it's legally better to not document a feature then to document a feature that requires a potentially complicated workaround and may cause system crashes/instability/etc, because of potential for lost revenue.
    – phyrfox
    Oct 5, 2018 at 4:54
  • 1
    Very good point, especially since the feature wasn’t used at the time, it would be much simpler for Intel to tell people not to use it than to explain how to work around the bugs.
    – Stephen Kitt
    Oct 5, 2018 at 7:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .