3 ms·

Nowadays CS, SS, DS, and ES are enforced to be 0 in 64 bit mode, leaving just FS and GS which are used for e.g. thread local storage

amluto 9y ago
Not true. The CS, SS, DS, and ES bases are ignored in 64-bit mode, but those registers still exist, still carry their full, extraordinarily complicated values, and are very much observable. Even on AMD Zen, for example, SS handling is screwed up enough that every context switch has added overhead to work around a SYSRET glitch that would otherwise risk executing user code with a messed up bit in the "hidden" part of SS. AMD should have killed these registers entirely in 64-bit user mode, but they didn't.
- yuhong 9y ago
  My understanding is that AMD probably originally designed SYSRET assuming that SS contained the correct values already (except SS.DPL of course, which I guess is where the stuff where they set it to RPL comes from). When they designed x86-64 however, they decided to set SS to null selectors in interrupts. Of course, these values are normally ignored in 64-bit long mode. Long mode is also when they fixed SYSCALL/SYSRET by adding an option to mask EFLAGS (and store the old value in R11): http://web.archive.org/web/20120813101603/http://www.x86-64.org:80/pipermail/discuss/2000-October/001019.html http://web.archive.org/web/20120813101603/http://www.x86-64....
  - yuhong 9y ago
    BTW, SYSENTER/SYSEXIT was designed by Andy Glew, which mentioned in https://groups.google.com/d/msg/comp.arch/Bf-4VflljF4/4hNvyrHN8pAJ https://groups.google.com/d/msg/comp.arch/Bf-4VflljF4/4hNvyr... that "(I wanted to avoid changing SS:ESP, so that it could be just a single register write if CS:EIP were co-renamed, but microcode thought that would violate invariants about SS RPL they wanted to maintain." I wonder if part of the problem is that AMD was still new to x86 CPU design back when SYSCALL/SYSRET was developed as part of the K6.

amluto 9y ago

Not true. The CS, SS, DS, and ES bases are ignored in 64-bit mode, but those registers still exist, still carry their full, extraordinarily complicated values, and are very much observable. Even on AMD Zen, for example, SS handling is screwed up enough that every context switch has added overhead to work around a SYSRET glitch that would otherwise risk executing user code with a messed up bit in the "hidden" part of SS. AMD should have killed these registers entirely in 64-bit user mode, but they didn't.

yuhong 9y ago
My understanding is that AMD probably originally designed SYSRET assuming that SS contained the correct values already (except SS.DPL of course, which I guess is where the stuff where they set it to RPL comes from). When they designed x86-64 however, they decided to set SS to null selectors in interrupts. Of course, these values are normally ignored in 64-bit long mode. Long mode is also when they fixed SYSCALL/SYSRET by adding an option to mask EFLAGS (and store the old value in R11): http://web.archive.org/web/20120813101603/http://www.x86-64.org:80/pipermail/discuss/2000-October/001019.html http://web.archive.org/web/20120813101603/http://www.x86-64....
- yuhong 9y ago
  BTW, SYSENTER/SYSEXIT was designed by Andy Glew, which mentioned in https://groups.google.com/d/msg/comp.arch/Bf-4VflljF4/4hNvyrHN8pAJ https://groups.google.com/d/msg/comp.arch/Bf-4VflljF4/4hNvyr... that "(I wanted to avoid changing SS:ESP, so that it could be just a single register write if CS:EIP were co-renamed, but microcode thought that would violate invariants about SS RPL they wanted to maintain." I wonder if part of the problem is that AMD was still new to x86 CPU design back when SYSCALL/SYSRET was developed as part of the K6.