As far as I understand, what's happening is: * There's an old feature which causes POP SS/MOV SS instructions to delay all interrupts until the next instructio

As far as I understand, what's happening is: * There's an old feature which causes POP SS/MOV SS instructions to delay all interrupts until the next instruction has executed, to safely allow changing both SS and SP without an interrupt firing inbetween on a bad stack. * If such an instruction itself causes an interrupt (by triggering a memory breakpoint through the debug registers), it is delayed (as intended). * The delayed interrupt will fire after the second instruction even if the second instruction disabled interrupts. * By means of the above, a MOV SS instruction triggering a #DB followed by an INT n instruction will cause the #DB exception to fire before the first instruction of the interrupt handler, even though this should be impossible (as entering the handlers sets IF=0, disabling interrupts). * The OS #DB handler assumes GS has been fixed up by the previous interrupt handler, which in now under user control.