Call gate (Intel)
A call gate is a mechanism in Intel's x86 architecture for changing the privilege level of a process when it executes a predefined function call using a CALL FAR instruction.
Overview
Call gates are intended to allow less privileged code to call code with a higher privilege level. This type of mechanism is essential in modern operating systems that employ memory protection since it allows user applications to use kernel functions and system calls in a way that can be controlled by the operating system.
Call gates use a special selector value to reference a descriptor accessed via the Global Descriptor Table or the Local Descriptor Table, which contains the information needed for the call across privilege boundaries. This is similar to the mechanism used for interrupts.
Usage
Assuming a call gate has been set up already by the operating system kernel, code simply does a CALL FAR with the necessary segment selector (the offset field is ignored). The processor will perform a number of checks to make sure the entry is valid and the code was operating at sufficient privilege to use the gate. Assuming all checks pass, a new CS/EIP is loaded from the segment descriptor, and continuation information is pushed onto the stack of the new privilege level (old SS, old ESP, old CS, old EIP in that order). Parameters may also be copied from the old stack to the new stack if needed. The number of parameters to copy is located in the call gate descriptor.
The kernel may return to the user space program by using a RET FAR instruction which pops the continuation information off the stack and returns to the outer privilege level.
Format of call gate descriptor
typedef struct _CALL_GATE
{
USHORT OffsetLow;
USHORT Selector;
UCHAR NumberOfArguments:5;
UCHAR Reserved:3;
UCHAR Type:5;
UCHAR Dpl:2;
UCHAR Present:1;
USHORT OffsetHigh;
}CALL_GATE,*PCALL_GATE;
Previous use
OS/2 was an early user of call gates to transfer between application code running in ring 3, privileged code running in ring 2, and kernel code in ring 0.
Windows 95 executes drivers and process switching in ring 0, while applications, including API DLL such as kernel32.dll and krnl386.exe are executed in ring 3. Driver VWIN32.VXD provides key operating system primitives at ring 0. It allows calling of driver functions from 16-bit applications (MSDOS and Win16). This address is obtained by calling INT 2Fh, with 1684h in the AX register. To identify which VxD an entry point is being requested for, the BX register is set to the 16-bit VxD ID. Upon return from the INT instruction, the ES.DI registers contain a far pointer that can be called to transfer control to the VxD running at ring 0. The descriptor pointed by ES is actually call gate.[1] 32-bit applications, however, when they need to access Windows 95 driver code, call undocumented VxDCall function in KERNEL32.DLL which essentially calls INT 30h, which changes ring mode.
Modern use
Modern x86 operating systems are transitioning away from CALL FAR call gates. With the introduction of SYSENTER/SYSEXIT and SYSCALL/SYSRET, a new faster mechanism was introduced for control transfers for x86 programs. And as most other architectures do not support call gates, their use was rare even before these new instructions as software interrupts/traps were preferred for portability.
Call gates are more flexible than the SYSENTER/SYSEXIT and SYSCALL/SYSRET instructions since unlike the latter two, call gates allow for changing from an arbitrary privilege level to an arbitrary (albeit higher or equal) privilege level. The fast SYS* instruction only allow control transfers from ring 3 to 0 and vice versa. Upon comparing call gates to interrupts, call gates are significantly faster.
Security issues
To preserve system security, the Global Descriptor Table should be held in protected memory, otherwise any program will be able to create its own call gate and use it to raise its privilege level. Call gates have sometimes been used as a vector for software security exploits, when ways have been found around this protection. One example of this is the E-mail worm Gurong.A written to exploit the Microsoft Windows operating system, which uses \Device\PhysicalMemory to install a call gate.
See also
References
- ^ Matt Pietrek, Windows 95 System programming SECRETS