시스템 호출

System call
시스템 명령과 혼동하지 마십시오.
다양한 컴포넌트와 사용자 공간 간의 통신을 처리하는 Linux 커널의 시스템 콜인터페이스 개요

컴퓨팅에서 시스템 호출(일반적으로 syscall로 줄임말)은 컴퓨터 프로그램이 서비스를 실행하는 운영 체제의 커널로부터 서비스를 요청하는 프로그래밍 방식입니다.여기에는 하드웨어 관련 서비스(하드디스크 드라이브 액세스나 디바이스 카메라 액세스 등), 새로운 프로세스의 작성과 실행, 프로세스 스케줄링과 같은 통합 커널 서비스와의 통신이 포함됩니다.시스템 콜은 프로세스와 운영체제 사이에 필수적인 인터페이스를 제공합니다.

대부분의 시스템에서 시스템 콜은 사용자 공간 프로세스에서만 실행할 수 있지만 일부 시스템에서는 OS/360 및 후속 시스템에서도 특권 시스템코드가 시스템콜을 [1]발행합니다

권한

일부 임베디드 시스템을 제외한 대부분의 최신 프로세서의 아키텍처는 보안 모델을 포함합니다.예를 들어 링 모델은 소프트웨어가 실행될 수 있는 여러 특권 수준을 지정합니다.일반적으로 프로그램은 실행 중인 다른 프로그램이나 운영체제 자체에 접근하거나 수정할 수 없도록 자체 주소 공간으로 제한되며 일반적으로 하드웨어 장치(프레임 버퍼나 네트워크 등)를 직접 조작하는 것은 금지됩니다.디바이스)를 참조해 주세요.

다만, 많은 애플리케이션은 이러한 컴포넌트에 액세스 할 필요가 있기 때문에, operating system에 의해서 시스템 콜을 사용할 수 있게 되어, 이러한 조작에 대해서 명확하게 정의되고 안전한 실장이 가능하게 됩니다.운영체제는 최고 수준의 특권으로 실행되며 대부분의 경우 인터럽트를 통해 시작되는 시스템콜을 통해 애플리케이션을 통해 서비스를 요구할 수 있습니다.인터럽트는 자동적으로 CPU를 높은 특권 레벨로 하고 나서, 커널에 제어를 넘깁니다.이것에 의해, 호출 프로그램에 요구된 서비스를 허가할 필요가 있는지 어떤지가 결정됩니다.서비스가 부여되면 커널은 호출 프로그램이 직접 제어하지 않는 특정 명령 세트를 실행하고 특권 수준을 호출 프로그램의 특권 수준으로 되돌린 다음 제어권을 호출 프로그램에 반환합니다.

도서관을 중개하다

일반적으로 시스템은 일반 프로그램과 운영 체제 사이에 있는 라이브러리 또는 API를 제공합니다.Unix와 같은 시스템에서 이 API는 보통 시스템콜에 래퍼 기능을 제공하는 c 라이브러리(libc 등) 구현의 일부입니다.이 기능은 종종 시스템콜이 호출하는 시스템콜과 같은 이름이 붙습니다.Windows NT에서는 이 API가 네이티브 API의 일부이며,ntdll.dll 라이브러리. 이는 일반 Windows API 구현에서 사용되는 문서화되어 있지 않은 API로 Windows 상의 일부 시스템프로그램에서 직접 사용됩니다.라이브러리의 래퍼 함수는 시스템 호출을 보다 모듈화 할 뿐만 아니라 시스템 호출을 사용하기 위한 일반적인 함수 호출 규칙(어셈블리 수준에서의 서브루틴 호출)을 노출합니다.여기서 래퍼의 주요 기능은 시스템콜에 전달되는 모든 인수를 적절한 프로세서레지스터(및 콜스택)에 배치하는 것과 동시에 커널이 호출하는 일의의 시스템콜 번호를 설정하는 것입니다.이와 같이 OS와 애플리케이션 사이에 존재하는 라이브러리는 휴대성을 향상시킵니다.

라이브러리 함수 자체에 대한 호출은 커널 모드로 전환되지 않으며 통상적인 서브루틴 호출입니다(예를 들어 일부 Instruction Set Architecture(ISA; 명령 집합 아키텍처)에서 "CALL" 어셈블리 명령을 사용합니다).실제 시스템 콜은 제어를 커널로 전송합니다(또한 라이브러리 콜을 추상화하는 것보다 구현 및 플랫폼에 더 의존합니다).예를 들어 Unix와 같은 시스템에서는fork그리고.execveC 라이브러리 함수입니다.이 함수는 다음 명령어를 실행하여 명령어를 호출하는 명령어를 실행합니다.fork그리고.exec시스템 콜애플리케이션 코드로 직접 시스템콜을 발신하는 것은 보다 복잡하며 임베디드 어셈블리코드를 사용해야 할 수 있습니다(C 및 C++).또, 시스템콜 조작에 필요한 로우 레벨의 바이너리 인터페이스에 대한 지식이 필요합니다.이러한 인터페이스는 시간이 지남에 따라 변경될 수 있기 때문에, 애플리케이션 바이너리 인터페이스의 일부가 아닙니다.함수는 이를 추상화하는 것을 의미합니다.

exokernel 기반 시스템에서는 라이브러리가 특히 중개자로서 중요합니다.exokernel에서 라이브러리는 매우 낮은 수준의 커널 API로부터 사용자 애플리케이션을 보호하고 추상화 및 리소스 관리를 제공합니다.

IBM의 OS/360 및 DOS/360은 대부분의 시스템 호출을 어셈블리 언어 [a]매크로 라이브러리를 통해 구현합니다. 단, 호출 연동이 있는 서비스는 몇 가지 있습니다.이는 어셈블리 언어로 프로그래밍하는 것이 높은 수준의 언어 사용보다 더 일반적이던 시절의 기원을 반영합니다.따라서 IBM 시스템 호출은 고급 언어 프로그램에서 직접 실행할 수 없었지만 호출 가능한 어셈블리 언어 래퍼 서브루틴이 필요했습니다.그 이후로 IBM은 z/OS 및 z/VSE와 같은 고급 언어로 호출할 수 있는 많은 서비스를 추가했습니다.

예 및 도구

Unix, Unix 및 기타 POSIX 준거 운영체제에서는 일반적인 시스템콜은 다음과 같습니다.open,read,write,close,wait,exec,fork,exit,그리고.kill . 현대의 많은 운영체제는 수백 개의 시스템 콜을 가지고 있습니다.예를 들어 리눅스 및 OpenBSD의 콜 수는 각각 300개 [2][3]이상, NetBSD의 콜 수는 [4]약 500개,[5] FreeBSD의 콜 수는 500개 이상, Windows의 콜 수는 2000개에 가깝고, win32k(그래픽)와 ntdl(코어)의[6] 시스템 콜 수는 [7]약 51개입니다.

strace, ftrace 및 truss 등의 툴을 사용하면 프로세스가 처음부터 실행되어 프로세스가 호출하는 모든 시스템콜을 보고할 수 있습니다.또, 조작이 유저의 권한을 위반하지 않는 경우는, 이미 실행중의 프로세스에 접속해, 상기 프로세스에 의해서 행해진 시스템콜을 대행 수신할 수도 있습니다.이 프로그램의 특별한 기능은 보통 ptrace와 같은 시스템 호출이나 procfs 파일의 시스템 호출에도 구현됩니다.

표준 구현

시스템 콜을 구현하려면 사용자 공간에서 커널 공간으로 제어 권한을 이전해야 합니다.이 공간에는 아키텍처 고유의 기능이 포함되어 있습니다.이를 구현하기 위한 일반적인 방법은 소프트웨어 인터럽트 또는 트랩을 사용하는 것입니다.운영체제 커널로의 전송 제어를 중단합니다.따라서 소프트웨어는 필요한 시스템콜 번호로 레지스터를 셋업하고 소프트웨어 인터럽트를 실행하면 됩니다.

이는 많은 RISC 프로세서에서 제공되는 유일한 기술이지만 x86 등의 CISC 아키텍처는 추가 기술을 지원합니다.예를 들어, x86 명령어 세트에는 명령어가 포함되어 있습니다.SYSCALL/SYSRET그리고.SYSENTER/SYSEXIT (이 두 가지 메커니즘은 각각 AMD와 Intel에 의해 독립적으로 개발되었지만 본질적으로는 동일한 작업을 수행합니다).이는 [8]인터럽트의 오버헤드 없이 시스템콜을 위해 커널에 제어를 신속하게 전송하도록 설계된 "고속" 제어 전송 명령입니다.Linux 2.5는 x86(사용 가능한 경우)에서 이 기능을 사용하기 시작했습니다.이전에는INT명령: 시스템콜번호가 배치되어 있습니다.EAX interrupt 0x80이 [9][10]실행되기 전에 등록해야 합니다.

오래된 메커니즘은 콜게이트입니다.원래는 Multics에서 사용되었습니다.예를 들어 인텔x86의 콜게이트를 참조해 주세요.운영 체제가 미리 설정한 안전 제어 전송 메커니즘을 사용하여 프로그램이 커널 함수를 직접 호출할 수 있습니다.이 어프로치는 x86 메모리세그먼트를 사용하는 원거리 콜(현재[11] 코드세그먼트가 아닌 다른 세그먼트에 있는 프로시저 호출)의 요건과 그로 인해 발생하는 이식성의 결여, 그리고 위에서 설명한 보다 빠른 명령의 존재로 인해 x86에서는 인기가 없었습니다.

IA-64 아키텍처의 경우EPC(특권코드 입력) 명령이 사용됩니다.처음 8개의 시스템콜 인수는 레지스터로 전달되고 나머지는 스택으로 전달됩니다.

IBM System/360 메인프레임 제품군 및 후속 제품군의 경우 레지스터가 아닌 명령어에 번호가 포함된 SVC(Supervisor Call Instruction)는 IBM[b] 자체 운영 체제 대부분에서 레거시 설비에 대한 시스템 호출과 Linux의 모든 시스템 호출을 구현합니다.MVS의 최신 버전에서 IBM은 많은 새로운 설비에 프로그램 호출(PC) 명령을 사용합니다.특히, PC 는, 발신자가 Service Request Block(SRB; 서비스 요청 블록) 모드일 가능성이 있는 경우에 사용됩니다.

PDP-11 미니컴퓨터는 IBM System/360 SVC 및 x86 INT와 마찬가지로 EMT 및 IOT 명령을 사용했습니다. 이 명령어는 특정 주소로 인터럽트를 생성하여 운영체제로 제어를 이양합니다.PDP-11 시리즈의 VAX 32비트 후계기에서는 CHMK, CHME 및 CHMS 명령을 사용하여 다양한 레벨의 특권 코드에 시스템콜을 발신했습니다이 코드는 명령의 인수입니다.

시스템 콜의 카테고리

시스템 콜은 크게 6가지 [12]카테고리로 분류할 수 있습니다.

  1. 프로세스 관리
  2. 파일 관리
    • 파일 생성, 파일 삭제
    • 열림, 닫힘
    • 읽기, 쓰기, 재배치
    • 파일 속성 가져오기/설정
  3. 디바이스 관리
    • 요구 디바이스, 릴리스 디바이스
    • 읽기, 쓰기, 재배치
    • 디바이스 속성 가져오기/설정
    • 논리적으로 디바이스 연결 또는 분리
  4. 정보 유지 관리
    • 전체 시스템 정보(시간, 날짜, 컴퓨터 이름, 기업 등)를 가져오거나 설정합니다.
    • 프로세스, 파일 또는 디바이스 메타데이터 가져오기/설정(작성자, 오프너, 작성 일시 등)
  5. 의사소통
    • 통신 연결 생성, 삭제
    • 메시지 보내기, 받기
    • 전송 상태 정보
    • 원격 장치 연결 또는 분리
  6. 보호.
    • 파일 권한 가져오기/설정

프로세서 모드 및 컨텍스트 전환

대부분의 Unix 유사 시스템에서 시스템콜은 커널모드로 처리되며 프로세서 실행모드를 특권 모드로 변경함으로써 처리되지만 특권 컨텍스트스위치는 필요 없습니다.하드웨어는 프로세서 상태 레지스터에 따라 실행 모드 측면에서 세계를 인식하며 프로세스는 운영 체제에서 제공하는 추상화입니다.시스템 콜은 일반적으로 다른 프로세스로의 컨텍스트스위치를 필요로 하지 않습니다.대신 [13][14]호출된 프로세스의 컨텍스트에서 처리됩니다.

멀티스레드 프로세스에서는 여러 스레드에서 시스템콜을 발신할 수 있습니다.이러한 콜의 처리는, 특정의 operating system의 커널과 애플리케이션의 런타임 환경의 설계에 의해서 다릅니다.다음 목록은 일반적인 모델과 운영 [15][16]체제를 보여 줍니다.

  • 다대일 모델:프로세스 내의 임의의 사용자 스레드로부터의 모든 시스템콜은 단일 커널레벨 스레드에 의해 처리됩니다.이 모델에는 중대한 단점이 있습니다.즉, (사용자로부터의 입력을 기다리는 등) 블로킹시스템 콜은 다른 모든 스레드를 정지시킬 수 있습니다.또, 한 번에 1개의 스레드만이 커널에 액세스 할 수 있기 때문에, 이 모델에서는 복수의 프로세서 코어를 이용할 수 없습니다.
  • 일대일 모델:각 사용자 스레드는 시스템콜 중에 개별 커널레벨 스레드에 접속됩니다.이 모델에서는 위의 시스템콜 차단 문제가 해결됩니다.주요 Linux 배포판, macOS, iOS, 최신 Windows 및 Solaris 버전에서 볼 수 있습니다.
  • 다대다 모델:이 모델에서는 사용자 스레드 풀이 커널 스레드 풀에 매핑됩니다.사용자 스레드 풀로부터의 모든 시스템콜은 대응하는 커널스레드 풀의 스레드에 의해 처리됩니다.
  • 하이브리드 모델:이 모델은 커널의 선택에 따라 다수의 모델과 1대1 모델을 모두 구현합니다.이 문제는 이전 버전의 IRIX, HP-UX 및 Solaris에서 볼 수 있습니다.

「 」를 참조해 주세요.

메모들

  1. ^ IBM은 SVC 번호, 매개 변수 레지스터와 같은 모든 경우에 대해 문서화했습니다.
  2. ^ CP-67 및 VM의 CP 컴포넌트는 진단(DIAG) 명령을 가상 머신에서 CP로의 하이퍼바이저 콜(HVC)로 사용합니다.

레퍼런스

  1. ^ IBM (March 1967). "Writing SVC Routines". IBM System/360 Operating System System Programmer's Guide (PDF). Third Edition. pp. 32–36. C28-6550-2.
  2. ^ "syscalls(2) - Linux manual page".
  3. ^ OpenBSD (14 September 2013). "System call names (kern/syscalls.c)". BSD Cross Reference.
  4. ^ NetBSD (17 October 2013). "System call names (kern/syscalls.c)". BSD Cross Reference.
  5. ^ "FreeBSD syscalls.c, the list of syscall names and IDs".
  6. ^ Author: Mateusz "j00ru" Jurczyk (5 November 2017). "Windows WIN32K.SYS System Call Table (NT/2000/XP/2003/Vista/2008/7/8/10)". {{cite web}}: author=범용명(도움말)이 있습니다.
  7. ^ "Plan 9 sys.h, the list of syscall names and IDs".
  8. ^ "SYSENTER (OSDev wiki)".
  9. ^ Anonymous (19 December 2002). "Linux 2.5 gets vsyscalls, sysenter support". KernelTrap. Retrieved 1 January 2008.
  10. ^ Manu Garg (2006). "Sysenter Based System Call Mechanism in Linux 2.6".
  11. ^ "Liberation: x86 Instruction Set Reference". renejeschke.de. Retrieved 4 July 2015.
  12. ^ Silberschatz, Abraham (2018). Operating System Concepts. Peter B Galvin; Greg Gagne (10th ed.). Hoboken, NJ: Wiley. p. 67. ISBN 9781119320913. OCLC 1004849022.
  13. ^ Bach, Maurice J.(1986), UNIX 운영체제 설계, 프렌티스 홀, 15-16페이지.
  14. ^ Elliot, John (2011). "Discussion of system call implementation at ProgClub including quote from Bach 1986".
  15. ^ "Threads".
  16. ^ "Threading Models" (PDF).

외부 링크