Task Gate, Interrupt Gate, Call Gate

Question

I tried to learn more about the different lines in the x86 architecture. If I understand correctly, then interrupts and traps are used to handle hw and sw interrupts, respectively. While the CALL-gate is probably no longer in use, as ppl prefer to replace SYSENTER and SYSEXIT.

I was wondering how task gates are used (I know that they are used to switch hw tasks). What does it mean? Task hw relates to an OS task / process. Or it is more like switching between two different instances of the operating system. (Maybe on the servers.)?

On the side of the note, it may happen that some of the interrupts are handled in user mode. (Can we handle division by zero interruption in user mode. If this can be, it means that the IDT handler record for division by zero contains an address from user space?)

thanks

Answer 1

Everything you can know about interrupts and gates is in the Intel Developer's Guide, Volume 3 . In short:

• Target gates were originally designed as a processor-mediated method for performing task switching; The CPU can automatically record the state of the process during the task switching operation. They are not commonly used on modern operating systems; The OS usually performs state-saving operations on its own.
• At least on Linux, all the interrupt handlers are in kernel space and run in ring 0. If you want to handle a zero-delimited exception, you register a user space signal handler for SIGFPE; the kernel-kernel interrupt handler calls the SIGFPE signal, which indirectly calls the user-space handler code (user-space code is executed after returning from the interrupt handler).

Answer 2

The state of affairs is that only interrupts and traps were actually used and remain in use. Theoretically, both of them can be used both for s / w and for handling h / w events. The only difference between the two is that calling the interrupt call automatically prohibits future interrupts, which may be useful in some cases of processing a hardware interrupt. By default, people try to use trap traps, because unnecessarily disabling interrupts is bad, because interrupting an interrupt increases the delay in processing interrupts and increases the likelihood of losing an interrupt. The call gate has never been used. This is inconvenient and not optimal for implementing a system call. Instead of a call gateway, most operating systems use a trap (int 0x80 on Linux and int 0x2E on Windows) or sysenter / sysexit syscall / sysrt. The target door has also never been used. This is not an optimal, inconvenient and limited feature, if not ugly. Instead, operating systems typically implement task switching for their part by switching kernel mode task stacks. Intel initially provided hardware support for multitasking by introducing TSS (task status segment) and Task Gate. In accordance with these functions, the processor is able to automatically save the state of one task and restore the state of another in response to a request received from hw or sw. The Sw request can be made by issuing call or jmp commands using the TSS selector or the task gate selector used as the instruction operand. The Hw request can be executed in hardware, moving to the task gate in the corresponding IDT record. But, as I mentioned, no one uses it. Instead, operating systems use only one TSS for all tasks (TSS should be used in any case, because during the transfer of control from the less privileged segment to the more privileged switch segments of the CPU and it grabs the stack address for the more privileged segment from TSS) and manually switch task.

In theory, interrupts and exceptions can be processed in user mode (ring 3), but in practice this is not useful, and the operating system processes all such events on the kernel side (in ring 0). The reason is simple: interrupts and exception handlers should always be in memory and be accessible from any address space. The core part of the address space is common and identical in all address spaces of all tasks in the system, but the user part of the address space is connected to a specific task. If you want to handle the exception in user mode, you will have to reprogram the IDT on each task switch, which will lead to a significant decrease in performance. If you want to handle interrupts the same way, you will be forced to share interrupt handlers between all tasks at the same addresses. As undesirable consequences, any task in the system will be able to ruin the handler.