Linux의 시스템 호출은 커널에 대한 합법적인 항목이 아닙니다.

Linux에서 시스템 호출은 사용자 공간이 커널에 액세스할 수 있는 유일한 방법입니다. 실제로 장치 파일, /proc 등 다른 메서드는 궁극적으로 시스템 호출을 통해 수행됩니다.

일반적으로 애플리케이션은 시스템 호출을 직접 통하지 않고 API(애플리케이션 프로그래밍 소켓)를 통해 프로그래밍되며, 이러한 프로그래밍 소켓은 실제로 커널에서 제공하는 시스템 호출에 대응할 필요가 없습니다. API는 애플리케이션에서 사용되는 프로그래밍 소켓 세트를 정의합니다. 하나의 시스템 호출로 구현하거나 여러 시스템 호출을 호출하여 구현할 수 있습니다. 시스템 호출을 사용하지 않아도 문제가 없습니다. 실제로 API는 다양한 운영 체제에서 구현되어 애플리케이션에 정확히 동일한 소켓을 제공할 수 있지만 이러한 시스템에서의 구현은 매우 다를 수 있습니다.

Unix 세계에서 가장 널리 사용되는 애플리케이션 프로그래밍 소켓은 POSIX 표준을 기반으로 하며 Linux는 POSIX와 호환됩니다.

프로그래머의 관점에서 보면 API만 다루면 되고 커널은 시스템 호출만 처리합니다. 라이브러리 기능과 응용 프로그램이 시스템 호출을 어떻게 사용하는지는 커널의 관심사가 아닙니다.

시스템 호출(Linux에서는 syscall이라고도 함)은 일반적으로 함수를 통해 호출됩니다. 일반적으로 하나 이상의 매개변수(입력) 정의가 필요하며 일부 부작용이 발생할 수 있습니다. 이 부작용은 성공(0 값) 또는 오류(음수 값)를 나타내는 긴 반환 값으로 표시됩니다. 시스템 호출에서 오류가 발생하면 오류 코드가 errno 전역 변수에 기록됩니다. perror() 함수를 호출하면 이 변수는 사용자가 이해할 수 있는 오류 문자열로 변환될 수 있습니다.

시스템 호출 구현에는 두 가지 특징이 있습니다. 1) 함수 선언에 asmlinkage 한정자가 있습니다. 이는 스택에서 함수의 매개변수만 추출하도록 컴파일러에 알리는 데 사용됩니다. 2) 시스템 호출 getXXX()는 커널에서 sys_getXXX()로 정의됩니다. 이는 Linux의 모든 시스템 호출이 따라야 하는 명명 규칙입니다.

시스템 호출 번호: Linux에서는 각 시스템 호출에 시스템 호출 번호가 할당되며 시스템 호출은 이 고유 번호와 연결될 수 있습니다. 사용자 공간 프로세스가 시스템 호출을 실행할 때 시스템 호출 번호는 실행될 시스템 호출을 나타내는 데 사용됩니다. 프로세스는 시스템 호출의 이름을 언급하지 않습니다. 시스템 호출 번호는 일단 할당되면 변경할 수 없습니다(그렇지 않으면 컴파일된 응용 프로그램이 중단됩니다). 시스템 호출이 삭제되면 해당 시스템 호출 번호는 재활용될 수 없습니다. Linux에는 -ENOSYS를 반환할 뿐만 아니라 다른 작업도 수행하지 않는 "사용되지 않는" 시스템 호출 sys_ni_syscall()이 있습니다. 이 오류 번호는 잘못된 시스템 호출을 위해 특별히 설계되었습니다. 드물게 보이지만 시스템 호출이 삭제되면 이 함수는 "간격을 채우는" 역할을 담당합니다.

커널은 등록된 모든 시스템 호출의 목록을 시스템 호출 테이블에 기록하고 이를 sys_call_table에 저장합니다. 이는 아키텍처와 관련이 있으며 일반적으로 항목에 정의되어 있습니다. 이 테이블은 각 유효한 시스템 호출에 고유한 시스템 호출 번호를 할당합니다.

사용자 공간 프로그램이 커널 코드를 직접 실행하는 것은 어렵습니다. 커널은 보호된 주소 공간에 있기 때문에 커널 공간에서 함수를 직접 호출할 수 없습니다. 애플리케이션은 어떤 형태로든 시스템에 시스템 호출을 실행해야 한다는 사실을 알려야 하며 시스템은 커널 상태로 전환됩니다. linux kernel call , 커널이 애플리케이션을 대신하여 시스템 호출을 실행할 수 있도록 합니다. 커널에 알리는 이러한 메커니즘은 소프트 인터럽트를 통해 구현됩니다. x86 시스템의 소프트 인터럽트는 int$0x80 명령어로 구성됩니다. 이 명령어는 예외를 발생시켜 시스템을 커널 모드로 전환하고 예외 처리기 번호 128을 실행하게 합니다. 이 프로그램은 시스템 호출 처리기이며 이름은 system_call()이며 하드웨어 아키텍처와 밀접하게 관련되어 있습니다. .s 파일의 어셈블리 언어로 컴파일된 항목에 있습니다.

모든 시스템 호출은 레드 플래그 Linux 시스템과 동일한 형태로 커널에 트랩되어 있으므로 커널 공간에 트랩하는 것만으로는 충분하지 않습니다. 따라서 시스템 호출 번호를 커널에 전달해야 합니다. x86에서 이 전송은 Softirq를 트리거하기 전에 eax 레지스터에 호출 번호를 배치하여 수행됩니다. 이런 방식으로 시스템 호출 핸들러가 실행되면 eax에서 데이터를 얻을 수 있습니다. 위에서 언급한 system_call()은 주어진 시스템 호출 번호를 NR_syscalls와 비교하여 유효성을 검사합니다. NR_syscalls보다 작거나 같으면 함수는 -ENOSYS를 반환합니다. 그렇지 않으면 해당 시스템 호출이 실행됩니다: call*sys_call_table(,%eax,4);

시스템 호출 테이블의 항목은 32비트(4바이트) 형식으로 저장되므로 커널은 주어진 시스템 호출 번호를 4로 나눈 다음 그 결과를 사용하여 테이블에서 장치의 위치를 ​​쿼리해야 합니다. . 그림 1과 같이:

시스템 호출 번호뿐만 아니라 일부 외부 매개변수 입력도 필요하다고 이미 언급했습니다. 가장 간단한 방법은 시스템 호출 번호를 전달하는 것처럼 이 매개변수를 레지스터에 저장하는 것입니다. x86 시스템에서 ebx, ecx, edx, esi 및 edi는 처음 5개의 매개변수를 순서대로 저장합니다. 6개 이상의 매개변수가 필요한 드문 경우에는 모든 매개변수의 사용자 공간 주소를 가리키는 포인터를 저장하기 위해 별도의 레지스터를 사용해야 합니다. 사용자 공간으로의 반환 값도 레지스터를 통해 전달됩니다. x86 시스템에서는 eax 레지스터에 저장됩니다.

시스템 호출은 모든 매개변수가 적법하고 유효한지 주의 깊게 확인해야 합니다. 시스템 호출은 커널 공간에서 실행됩니다. 사용자가 커널에 불법 입력을 전달하도록 허용되면 시스템의 보안과 안정성이 큰 테스트에 직면하게 됩니다. 가장 중요한 테스트는 사용자가 제공한 감시 포인터가 유효한지 여부를 검색하는 것입니다. 커널은 사용자 공간 감시 포인터를 수신하기 전에 다음을 확인해야 합니다.

1) 시계 바늘이 가리키는 메모리 영역은 사용자 공간에 속합니다

2) 시계 바늘이 가리키는 메모리 영역은 프로세스의 주소 공간에 있습니다

3) 읽고 있는 경우에는 읽은 메모리를 읽을 수 있음으로 표시해야 합니다. 쓰는 경우 메모리는 쓰기 가능으로 표시되어야 합니다.

커널은 필요한 감지를 완료하고 커널 공간과 사용자 공간 간에 데이터를 앞뒤로 복사하는 두 가지 방법을 제공합니다. 이 두 메서드 중 하나를 호출해야 합니다.

copy_to_user(): 3개의 매개변수가 필요한 사용자 공간에 데이터를 씁니다. 첫 번째 매개변수는 프로세스 공간의 대상 메모리 주소입니다. 두 번째는 커널 공간의 소스 주소입니다

.세 번째는 복사해야 하는 데이터 너비(바이트 수)입니다.

copy_from_user(): 사용자 공간에서 데이터를 읽으려면 3개의 매개변수가 필요합니다. 첫 번째 매개변수는 프로세스 공간의 대상 메모리 주소입니다. 두 번째는 커널 공간의 소스입니다

주소. 세 번째는 복사해야 하는 데이터 너비(바이트 수)입니다.

참고: 두 가지 모두 방해를 일으킬 수 있습니다. 이러한 상황은 사용자 데이터가 포함된 페이지가 수학 메모리가 아닌 하드 디스크로 교체될 때 발생합니다. 이때 linux 커널이 호출되고 페이지 결함 처리기가 하드 디스크의 페이지를 다시 화학 메모리로 교체할 때까지 프로세스는 절전 모드로 유지됩니다.

시스템 호출을 실행할 때 커널은 프로세스 컨텍스트에 있으며 현재 포인터는 시스템 호출을 발생시킨 프로세스인 현재 작업을 가리킵니다. 프로세스의 맥락에서 커널은 잠자기 상태일 수 있지만(예를 들어 시스템 호출을 차단하거나 명시적으로 Schedule()을 호출하는 동안) 점유될 수 있습니다. 시스템 호출이 반환되면 제어는 system_call()에 남아 있으며, 이는 궁극적으로 사용자 공간으로 전환하고 사용자 프로세스가 계속 실행되도록 하는 책임을 집니다.

리눅스에 시스템 호출 시간을 추가하는 것은 매우 간단합니다. 시스템 호출을 어떻게 설계하고 구현하느냐가 딜레마입니다. 시스템 호출 구현의 첫 번째 단계는 목적을 결정하는 것입니다. 이 목적은 명확하고 고유해야 합니다. 다목적 시스템 호출을 작성하려고 하지 마십시오. ioctl은 백엔드 교육 자료입니다. 새로운 시스템 호출의 매개변수, 반환 값, 오류 코드는 매우 중요합니다. 시스템 호출이 컴파일되면 이를 향후 시스템 호출로 등록하는 것은 지루한 작업이며 일반적으로 다음 단계를 따릅니다.

1) 시스템 호출 테이블 끝에 항목을 추가합니다(일반적으로 Entry.s에 있음). 테이블에서 시스템 항목의 위치는 0부터 시작하여 해당 시스템 호출 번호입니다. 첫 번째

10개의 시스템 콜이 시스템 콜 번호 9에 할당됩니다

2) 모든 아키텍처의 경우 시스템 호출 번호는 include/asm/unistd.h

에 정의되어야 합니다.

3) 시스템 호출은 커널 이미지로 컴파일되어야 합니다(모듈로 컴파일될 수 없음). 이것은 단지 kernel/ 아래의 관련 파일에 넣어지면 됩니다.

일반적으로 시스템 호출은 C 라이브러리에서 지원됩니다. 사용자 프로그램은 표준 헤더 파일을 포함하고 C 라이브러리와 연결하여 시스템 호출을 사용할 수 있습니다(또는 실제로 호출되는 라이브러리 함수를 사용할 수 있습니다). 다행스럽게도 Linux 자체에서는 시스템 호출에 직접 액세스할 수 있는 매크로 세트를 제공합니다. 레지스터를 설정하고 int$0x80 명령어를 호출합니다. 이 매크로는 _syscalln()이며, 여기서 n의 범위는 0부터 6까지입니다. 이는 시스템 호출에 전달되어야 하는 매개변수의 수를 나타냅니다. 이는 매크로가 레지스터에 푸시되는 인수 수와 순서를 정확히 알아야 하기 때문입니다. 개방형 시스템 호출을 예로 들어보겠습니다.

open() 시스템 호출은 다음과 같이 정의됩니다.

longopen(constchar*파일 이름,intflags,intmode)

이 시스템 호출의 매크로를 직접 호출하는 방법은 다음과 같습니다.

#defineNR_open5

_syscall3(long,open,constchar*,filename,int,flags,int,mode)

이런 방식으로 애플리케이션은 open() 시스템 호출을 호출하고 애플리케이션 내부에 매크로를 직접 배치할 수 있습니다. 각 매크로에는 2+2*n 매개변수가 있습니다. 각 매개변수의 의미는 간단하고 명확하므로 여기서는 자세히 설명하지 않습니다.

위 내용은 Linux의 시스템 호출은 커널에 대한 합법적인 항목이 아닙니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!