There are certain situations where interrupts are undesirable, so they are disabled.
The examples are numerous, but from my head I can come up with:
Modification ss:(e)sp . If the interrupt is triggered, the flags register is flags onto the stack. An invalid stack value will transfer this copy to a random location. Changing ss:(e)sp not atomic, at least on x86, since it consists of several instructions, so an interrupt can fire between them.
However, if you write your code correctly, you can achieve the same atomicity without disabling interrupts here, because they are automatically disabled in certain cases .
@MichaelPetch said some things about the 8088 processors (the “weaker brother” 8086, the first x86 processor), depicting the exception to these “specific cases” in the comments to this answer:
This is true that interrupts are disabled until the end of the next instruction (after moving the value to SS ), but there were 8088 processors with an error where interrupts were not properly disabled after changing the SS . Those of us (dinosaurs) often put CLI / STI around the SS:SP update just in case (the probability of starting an 8088 system with such an error is probably close to zero). From a historical perspective, this personalized PC article can shed light on this ancient issue.
(code formatting added.)
- Lack of IDT / IVT. . If the protected mode IDT is initialized or the 16-bit Real IVT is changed (or reset to zero or something else), the interrupt will be moved to some place in the memory; there is no instruction.
In general, you can say that operations that modify IDT / IVT in some non-atomic mode should disable interrupts.
On the sidelines: I myself have written several bootloaders and usually disables interrupts throughout the bootloader runtime. In protected mode, I eventually recreate them. Linux 4.2 handles it the same way. If you're interested, read its source code ( /arch/x86/boot/ ) or the Minix file!