6 ms·

> To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to

> To fix this, the CPU has a wild card: When you change SS, you get exactly 1 instruction that will not be interrupted. The idea is you use that instruction to change (e/r)SP and make the stack valid again. If there is a need for an interrupt, it will be delayed for 1 instruction. I wonder, why could not they make a single instruction to change both SS and SP?

vardump 8y ago
They probably could, but it would have had a large silicon cost for 1980 without performance benefit. That and ISA incompatibility.
- codedokode 8y ago
  Adding an interrupt delay is also not free and requires changes on hardware level. But if it was done in 80s then of course it was a safe hack because there was no kernel and user mode isolation at that time.
- hyperman1 8y ago
  The cost would not have been very big. The 8086 had microcode, and there were the very similar LDS and LES instructions. There were plenty of unused slots in the opcode table so that wasnt it the reason either. There are weird instructions aplenty like XLAT or AAA/AAS/AAD/AAM, so it wasnt as if they had a pressing silicon shortage. Maybe they dindt think about it, and fixed it with a quick hack once they got aware of the problem? The whole segment register story was very hacky from the start. Intel might have dumped the segment registers in i386 32 bit protected mode, as they cleaned up a lot of other troublesome corners around that time. But, well, they didn't, so we have to deal with it today.
  - ithkuil 8y ago
    They also had a more recent chance to clean up this with the which to 64 bit
  - yuhong 8y ago
    The fun thing is the 286 didn't fix this either. This is why the MOV SS came first (in protected mode the selector may not be present for example). This was a problem for DOS where SS was often used to access the DOS data segment.
tych0 8y ago
You could, but it wouldn't allow them to relax the constraints here, since you'd have to recompile all the code in the world to use this new instruction before relaxing.
Someone 8y ago
They could, but attackers would still use the approach that works for them. And they can’t really remove the old instructions because of backwards compatibility. Whitelisting a limited set of instructions that can follow setting SS and making all others trap might be an option, though. It still would break backwards compatibility, but if the effective impact would be negligible, they could deem it acceptable.
- shawnz 8y ago
  They could only do the interrupt disabling behaviour if the next instruction is in the whitelist, but not otherwise. EDIT: Although I guess it's almost certain to be an error anyway if it's not a whitelisted instruction.
- Someone 8y ago
  Follow-up: not only could they, they did. https://software.intel.com/sites/default/files/managed/7c/f1/253667-sdm-vol-2b.pdf https://software.intel.com/sites/default/files/managed/7c/f1..., page 4-385: “Loading the SS register with a POP instruction suppresses or inhibits some debug exceptions and inhibits interrupts on the following instruction boundary. (The inhibition ends after delivery of an exception or the execution of the next instruction.) This behavior allows a stack pointer to be loaded into the ESP register with the next instruction (POP ESP) before an event can be delivered. See Section 6.8.3, “Masking Exceptions and Interrupts When Switching Stacks,” in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. Intel recommends that software use the LSS instruction to load the SS register and ESP together.”
- yuhong 8y ago
  I bet whitelisting only instructions that can change SP/ESP would not break the majority of x86 code. All other instructions would behave as if MOV SS had not been executed.
hyperman1 8y ago
There are. I suppose LSS SP,value is possible on i386+ and there is also the task state segment which might help. But this was a hack in the original 8086, which wasnt the best processor design ever to start with. It stays there because of backward compatibility.
himom 8y ago
In protected mode, SS is a descriptor offset into the GDT. It doesn’t make sense to change SS very often unless there are multiple stacks. Furthermore, it doesn’t make sense to overcomplicate an already over-complicated instruction set burdened with vestigal, legacy features. And, loading SS and SP atomtically would probably create a byte pattern that’s too long to encode.
monocasa 8y ago
They use the same scheme other places as well. sti hlt will hold off on enabling the interrupts until right after the hlt has started so that you don't end up in a race condition when you get an interrupt between sti and hlt. Albeit, they could have made an stiandhlt instruction here as well.
- yuhong 8y ago
  That one will take trace exceptions though.
  - monocasa 8y ago
    Sure, that makes sense. A trace exception shouldn't be creating work for a thread context that's ostensibly the one going to sleep with nothing to do, but an external interrupt very likely is.

vardump 8y ago

They probably could, but it would have had a large silicon cost for 1980 without performance benefit. That and ISA incompatibility.

codedokode 8y ago
Adding an interrupt delay is also not free and requires changes on hardware level. But if it was done in 80s then of course it was a safe hack because there was no kernel and user mode isolation at that time.
hyperman1 8y ago
The cost would not have been very big. The 8086 had microcode, and there were the very similar LDS and LES instructions. There were plenty of unused slots in the opcode table so that wasnt it the reason either. There are weird instructions aplenty like XLAT or AAA/AAS/AAD/AAM, so it wasnt as if they had a pressing silicon shortage. Maybe they dindt think about it, and fixed it with a quick hack once they got aware of the problem? The whole segment register story was very hacky from the start. Intel might have dumped the segment registers in i386 32 bit protected mode, as they cleaned up a lot of other troublesome corners around that time. But, well, they didn't, so we have to deal with it today.
- ithkuil 8y ago
  They also had a more recent chance to clean up this with the which to 64 bit
- yuhong 8y ago
  The fun thing is the 286 didn't fix this either. This is why the MOV SS came first (in protected mode the selector may not be present for example). This was a problem for DOS where SS was often used to access the DOS data segment.

tych0 8y ago

You could, but it wouldn't allow them to relax the constraints here, since you'd have to recompile all the code in the world to use this new instruction before relaxing.

Someone 8y ago

They could, but attackers would still use the approach that works for them. And they can’t really remove the old instructions because of backwards compatibility. Whitelisting a limited set of instructions that can follow setting SS and making all others trap might be an option, though. It still would break backwards compatibility, but if the effective impact would be negligible, they could deem it acceptable.

shawnz 8y ago
They could only do the interrupt disabling behaviour if the next instruction is in the whitelist, but not otherwise. EDIT: Although I guess it's almost certain to be an error anyway if it's not a whitelisted instruction.
Someone 8y ago
Follow-up: not only could they, they did. https://software.intel.com/sites/default/files/managed/7c/f1/253667-sdm-vol-2b.pdf https://software.intel.com/sites/default/files/managed/7c/f1..., page 4-385: “Loading the SS register with a POP instruction suppresses or inhibits some debug exceptions and inhibits interrupts on the following instruction boundary. (The inhibition ends after delivery of an exception or the execution of the next instruction.) This behavior allows a stack pointer to be loaded into the ESP register with the next instruction (POP ESP) before an event can be delivered. See Section 6.8.3, “Masking Exceptions and Interrupts When Switching Stacks,” in Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. Intel recommends that software use the LSS instruction to load the SS register and ESP together.”
yuhong 8y ago
I bet whitelisting only instructions that can change SP/ESP would not break the majority of x86 code. All other instructions would behave as if MOV SS had not been executed.

hyperman1 8y ago

There are. I suppose LSS SP,value is possible on i386+ and there is also the task state segment which might help. But this was a hack in the original 8086, which wasnt the best processor design ever to start with. It stays there because of backward compatibility.

himom 8y ago

In protected mode, SS is a descriptor offset into the GDT. It doesn’t make sense to change SS very often unless there are multiple stacks. Furthermore, it doesn’t make sense to overcomplicate an already over-complicated instruction set burdened with vestigal, legacy features. And, loading SS and SP atomtically would probably create a byte pattern that’s too long to encode.

monocasa 8y ago

They use the same scheme other places as well. sti hlt will hold off on enabling the interrupts until right after the hlt has started so that you don't end up in a race condition when you get an interrupt between sti and hlt. Albeit, they could have made an stiandhlt instruction here as well.

yuhong 8y ago
That one will take trace exceptions though.
- monocasa 8y ago
  Sure, that makes sense. A trace exception shouldn't be creating work for a thread context that's ostensibly the one going to sleep with nothing to do, but an external interrupt very likely is.