Системные вызовы: интерфейс между программой и ядром ОС

Введение

Способ для программ доступа к службам ядра

В вычислительной технике системный вызов (обычно сокращается до syscall) — это программный способ, с помощью которого компьютерная программа запрашивает сервис у операционной системы, на которой она выполняется. Это может включать сервисы, связанные с аппаратным обеспечением (например, доступ к жесткому диску или камере устройства), создание и запуск новых процессов, а также взаимодействие с основными службами ядра, такими как планирование процессов. Системные вызовы обеспечивают необходимый интерфейс между процессом и операционной системой. В большинстве систем системные вызовы могут выполняться только из процессов пользовательского пространства, в то время как в некоторых системах, например OS/360 и её последователях, привилегированный системный код также использует системные вызовы. Для встраиваемых систем системные вызовы обычно не меняют режим привилегий процессора.

Привилегии

Архитектура большинства современных процессоров, за исключением некоторых встраиваемых систем, предусматривает модель безопасности. Например, модель колец определяет несколько уровней привилегий, под которыми может выполняться программное обеспечение: программа обычно ограничена своим собственным адресным пространством, чтобы она не могла получить доступ или изменить другие запущенные программы или саму операционную систему, и обычно ей запрещено напрямую манипулировать аппаратными устройствами (например, буфером кадра или сетевыми устройствами). Однако многим приложениям требуется доступ к этим компонентам, поэтому операционная система предоставляет системные вызовы для обеспечения чётко определенных и безопасных реализаций таких операций. Операционная система выполняется на самом высоком уровне привилегий и позволяет приложениям запрашивать сервисы через системные вызовы, которые часто инициируются прерываниями. Прерывание автоматически переводит процессор на повышенный уровень привилегий и затем передаёт управление ядру, которое определяет, следует ли предоставлять запрашиваемый сервис вызывающей программе. Если сервис предоставляется, ядро выполняет определённый набор инструкций, над которым вызывающая программа не имеет прямого контроля, возвращает уровень привилегий к уровню вызывающей программы, а затем возвращает управление вызывающей программе.

Библиотека как посредник

Как правило, системы предоставляют библиотеку или API, который располагается между обычными программами и операционной системой. В системах, подобных Unix, этот API обычно является частью реализации библиотеки C (libc), такой как glibc, предоставляющей функции-оболочки для системных вызовов, часто названные так же, как и сами системные вызовы, которые они вызывают. В Windows NT этот API является частью Native API, находящегося в библиотеке; это недокументированный API, используемый реализациями обычного Windows API и непосредственно некоторыми системными программами в Windows. Функции-оболочки библиотеки предоставляют стандартную конвенцию вызова функций (вызов подпрограммы на уровне ассемблера) для использования системного вызова, а также делают системный вызов более модульным. Основная функция оболочки заключается в размещении всех аргументов, которые должны быть переданы системному вызову, в соответствующие регистры процессора (и, возможно, в стек вызовов), а также в установке уникального номера системного вызова для вызова ядра. Таким образом, библиотека, находящаяся между ОС и приложением, повышает переносимость. Сам вызов функции библиотеки не вызывает переключения в режим ядра и обычно является обычным вызовом подпрограммы (например, с использованием инструкции "CALL" в некоторых архитектурах наборов команд (ISA)). Фактический системный вызов передает управление ядру (и больше зависит от реализации и платформы, чем от абстрагирующего его библиотечного вызова). Например, в системах, подобных Unix, fork и execve — это функции библиотеки C, которые, в свою очередь, выполняют инструкции, вызывающие системные вызовы fork и exec. Непосредственное выполнение системного вызова в коде приложения более сложно и может потребовать использования встроенного ассемблерного кода (в C и C++), а также знания низкоуровневого бинарного интерфейса для операции системного вызова, который может изменяться со временем и, следовательно, не является частью бинарного интерфейса приложения; функции библиотеки предназначены для абстрагирования этого. В системах на основе экзоядра библиотека особенно важна как посредник. В экзоядрах библиотеки защищают пользовательские приложения от очень низкоуровневого API ядра и предоставляют абстракции и управление ресурсами. В IBM OS/360, DOS/360 и TSS/360 большинство системных вызовов реализуются через библиотеку макросов языка ассемблера, хотя есть несколько сервисов с связью вызовов. Это отражает их происхождение во времена, когда программирование на языке ассемблера было более распространено, чем использование языков высокого уровня. Поэтому системные вызовы IBM не могли быть непосредственно выполнены программами высокого уровня, но требовали вызываемой подпрограммы-оболочки на языке ассемблера. С тех пор IBM добавила множество сервисов, которые могут быть вызваны из языков высокого уровня, например, в z/OS и z/VSE. В более поздних версиях MVS/SP и во всех последующих версиях MVS некоторые макросы системных вызовов генерируют Program Call (PC).

Generally, systems provide a library or API that sits between normal programs and the operating system. On Unix like systems, that API is usually part of an implementation of the C library (libc), such as glibc, that provides wrapper functions for the system calls, often named the same as the system calls they invoke. On Windows NT, that API is part of the Native API, in the library; this is an undocumented API used by implementations of the regular Windows API and directly used by some system programs on Windows. The library's wrapper functions expose an ordinary function calling convention (a subroutine call on the assembly level) for using the system call, as well as making the system call more modular. Here, the primary function of the wrapper is to place all the arguments to be passed to the system call in the appropriate processor registers (and maybe on the call stack as well), and also setting a unique system call number for the kernel to call. In this way the library, which exists between the OS and the application, increases portability. The call to the library function itself does not cause a switch to kernel mode and is usually a normal subroutine call (using, for example, a "CALL" assembly instruction in some Instruction set architectures (ISAs)). The actual system call does transfer control to the kernel (and is more implementation dependent and platform dependent than the library call abstracting it). For example, in Unix like systems, fork and execve are C library functions that in turn execute instructions that invoke the fork and exec system calls. Making the system call directly in the application code is more complicated and may require embedded assembly code to be used (in C and C++), as well as requiring knowledge of the low level binary interface for the system call operation, which may be subject to change over time and thus not be part of the application binary interface; the library functions are meant to abstract this away. On exokernel based systems, the library is especially important as an intermediary. On exokernels, libraries shield user applications from the very low level kernel API, and provide abstractions and resource management. IBM's OS/360, DOS/360 and TSS/360 implement most system calls through a library of assembly language macros, although there are a few services with a call linkage. This reflects their origin at a time when programming in assembly language was more common than high level language usage. IBM system calls were therefore not directly executable by high level language programs, but required a callable assembly language wrapper subroutine. Since then, IBM has added many services that can be called from high level languages in, e. g., z/OS and z/VSE. In more recent release of MVS/SP and in all later MVS versions, some system call macros generate Program Call (PC).

Примеры и инструменты

На Unix, Unix-подобных и других операционных системах, соответствующих стандарту POSIX, популярными системными вызовами являются open, read, write, close, wait, exec, fork, exit и kill. Многие современные операционные системы имеют сотни системных вызовов. Например, в Linux и OpenBSD насчитывается более 300 различных вызовов, в NetBSD – около 500, в FreeBSD – более 500, в Windows – около 2000, разделенных между графическими (win32k) и основными (ntdll) системными вызовами, а в Plan 9 – 51. Инструменты, такие как strace, ftrace и truss, позволяют отслеживать выполнение процесса с самого начала и регистрировать все системные вызовы, которые он выполняет, или подключаться к уже запущенному процессу и перехватывать любые системные вызовы, сделанные этим процессом, если операция не нарушает прав доступа пользователя. Эта особенность программ обычно также реализуется с помощью системных вызовов, таких как ptrace, или системных вызовов к файлам в procfs.

Типичные варианты реализации

Реализация системных вызовов требует передачи управления из пользовательского пространства в пространство ядра, что включает в себя специфическую особенность архитектуры. Типичный способ реализации – использование программного прерывания или ловушки. Прерывания передают управление ядру операционной системы, поэтому программному обеспечению достаточно установить в регистр необходимый номер системного вызова и выполнить программное прерывание. Это единственная техника, предоставляемая для многих RISC-процессоров, но архитектуры CISC, такие как x86, поддерживают дополнительные методы. Например, набор инструкций x86 содержит инструкции SYSCALL/SYSRET и SYSENTER/SYSEXIT (эти два механизма были независимо разработаны AMD и Intel соответственно, но по сути выполняют одно и то же). Это "быстрые" инструкции передачи управления, предназначенные для оперативной передачи управления ядру для системного вызова без накладных расходов, связанных с прерыванием. Linux 2.5 начал использовать их на x86, где это было возможно; ранее использовалась инструкция INT, при которой номер системного вызова помещался в регистр EAX перед выполнением прерывания 0x80. Более ранний механизм – шлюз вызова, изначально использовавшийся в Multics, а позже, например, в Intel x86. Он позволяет программе напрямую вызывать функцию ядра, используя безопасный механизм передачи управления, который операционная система настраивает заранее. Этот подход оказался непопулярным на x86, вероятно, из-за требования к дальнему вызову (вызову процедуры, расположенной в другом сегменте, чем текущий сегмент кода), который использует сегментацию памяти x86 и, как следствие, приводит к недостаточной переносимости, а также из-за существования более быстрых инструкций, упомянутых выше. Для архитектуры IA-64 используется инструкция EPC (Enter Privileged Code). Первые восемь аргументов системного вызова передаются в регистрах, а остальные – через стек. В семействе мэйнфреймов IBM System/360 и их преемниках инструкция Supervisor Call, содержащая номер в самой инструкции, а не в регистре, реализует системный вызов для устаревших функций в большинстве операционных систем IBM и для всех системных вызовов в Linux. В более поздних версиях MVS IBM использует инструкцию Program Call (PC) для многих новых функций. В частности, PC используется, когда вызывающая сторона может находиться в режиме "Блок запроса обслуживания" (Service Request Block, SRB). Миникомпьютер PDP-11 использовал инструкции , и , которые, подобно инструкциям IBM System/360 и x86, помещали код в саму инструкцию; они генерировали прерывания по конкретным адресам, передавая управление операционной системе. 32-битный преемник PDP-11, VAX, использовал инструкции , , и для выполнения системных вызовов к привилегированному коду на различных уровнях; код является аргументом инструкции.

Implementing system calls requires a transfer of control from user space to kernel space, which involves some sort of architecture specific feature. A typical way to implement this is to use a software interrupt or trap. Interrupts transfer control to the operating system kernel, so software simply needs to set up some register with the system call number needed, and execute the software interrupt. This is the only technique provided for many RISC processors, but CISC architectures such as x86 support additional techniques. For example, the x86 instruction set contains the instructions SYSCALL/SYSRET and SYSENTER/SYSEXIT (these two mechanisms were independently created by AMD and Intel, respectively, but in essence they do the same thing). These are "fast" control transfer instructions that are designed to quickly transfer control to the kernel for a system call without the overhead of an interrupt. Linux 2.5 began using this on the x86, where available; formerly it used the INT instruction, where the system call number was placed in the EAX register before interrupt 0x80 was executed. An older mechanism is the call gate; originally used in Multics and later, for example, see call gate on the Intel x86. It allows a program to call a kernel function directly using a safe control transfer mechanism, which the operating system sets up in advance. This approach has been unpopular on x86, presumably due to the requirement of a far call (a call to a procedure located in a different segment than the current code segment) which uses x86 memory segmentation and the resulting lack of portability it causes, and the existence of the faster instructions mentioned above. For IA 64 architecture, EPC (Enter Privileged Code) instruction is used. The first eight system call arguments are passed in registers, and the rest are passed on the stack. In the IBM System/360 mainframe family, and its successors, a Supervisor Call instruction , with the number in the instruction rather than in a register, implements a system call for legacy facilities in most of IBM's own operating systems, and for all system calls in Linux. In later versions of MVS, IBM uses the Program Call (PC) instruction for many newer facilities. In particular, PC is used when the caller might be in Service Request Block (SRB) mode. The PDP 11 minicomputer used the , and instructions, which, similar to the IBM System/360 and x86 , put the code in the instruction; they generate interrupts to specific addresses, transferring control to the operating system. The VAX 32 bit successor to the PDP 11 series used the , , and instructions to make system calls to privileged code at various levels; the code is an argument to the instruction.

Переключение режима процессора и контекста

Системные вызовы в большинстве Unix-подобных систем обрабатываются в режиме ядра, что достигается путем переключения процессора в более привилегированный режим исполнения, однако переключение контекста процесса не требуется, хотя и происходит переключение контекста привилегий. Аппаратное обеспечение воспринимает мир в терминах режима исполнения, определяемого регистром состояния процессора, а процессы являются абстракцией, предоставляемой операционной системой. Системный вызов, как правило, не требует переключения контекста на другой процесс; вместо этого он обрабатывается в контексте процесса, который его вызвал. В многопоточном процессе системные вызовы могут выполняться из нескольких потоков. Обработка таких вызовов зависит от архитектуры конкретного ядра операционной системы и среды выполнения приложения. Ниже приведен список типичных моделей, используемых операционными системами:

Модель "многие к одному": все системные вызовы от любого пользовательского потока в процессе обрабатываются одним потоком на уровне ядра. Эта модель имеет серьезный недостаток: любой блокирующий системный вызов (например, ожидание ввода от пользователя) может привести к зависанию всех остальных потоков. Кроме того, поскольку одновременно к ядру может получить доступ только один поток, эта модель не может использовать несколько ядер процессора. Модель "один к одному": каждый пользовательский поток привязывается к отдельному потоку ядра во время системного вызова. Эта модель решает проблему блокировки системных вызовов. Она используется во всех основных дистрибутивах Linux, macOS, iOS, последних версиях Windows и Solaris. Модель "многие ко многим": в этой модели пул пользовательских потоков отображается на пул потоков ядра. Все системные вызовы из пула пользовательских потоков обрабатываются потоками в соответствующем пуле потоков ядра. Гибридная модель: эта модель реализует как модель "многие ко многим", так и модель "один к одному" в зависимости от выбора, сделанного ядром. Она встречается в старых версиях IRIX, HP-UX и Solaris.