리눅스 시스템 호출 및 커널 모드

Question

read() 시스템 호출을 사용하여 HDD에 액세스하는 것과 같이 사용자 공간에서 허용되지 않는 기능에 대한 액세스를 제공하는 시스템 호출이 있다는 것을 알고 있습니다. 또한 하드웨어간에 호환성을 제공하기 위해 fread()과 같은 라이브러리 호출 형식의 사용자 모드 레이어로 추상화되어 있음을 이해합니다.

그래서 응용 프로그램 개발자의 관점에서 우리는 뭔가가처럼;

//library //syscall //k_driver //device_driver 
fread() -> read() -> k_read() -> d_read() 

내 질문은, fread() 및 read()의 모든 명령어를 내 프로그램에 직접 인라인하는 것을 중단하는 것은 무엇입니까? 지침은 동일하므로 CPU가 동일한 방식으로 작동해야합니까? 나는 그것을 시도하지 않았지만, 나는 이것이 실종되었다고 생각하는 이유로 작동하지 않는다고 가정한다. 그렇지 않으면 임의의 응용 프로그램이 임의의 커널 모드 작업을 수행 할 수 있습니다. 012 : DR : 시스템 호출이 응용 프로그램에서 복사 할 수없는 커널 모드에 들어가도록 허용하는 기능은 무엇입니까?

Answer 1

시스템 호출은 커널 자체에 들어 가지 않습니다. 보다 정확하게 예를 들어, 호출하는 읽기 기능은 응용 프로그램에 관한 한 라이브러리 호출입니다. 어떤 read(2)이 내부적으로 어떤 인터럽트 또는 syscall(2) 어셈블리 명령어를 사용하여 실제 시스템 호출을 호출하는지는 CPU 아키텍처와 OS에 따라 다릅니다.

이것은 사용자 코드가 실행되는 권한 코드를 갖는 유일한 방법이지만 간접적 인 방법입니다. 사용자 영역과 커널 코드는 다른 상황에서 실행됩니다.

즉, 커널 소스 코드를 사용자 코드에 추가 할 수 없으며 아무런 도움이되지 않지만 충돌이 발생할 수 있습니다. 특히 커널 코드는 하드웨어와 상호 작용하는 데 필요한 물리적 메모리 주소에 액세스 할 수 있습니다. Userland 코드는이 기능이없는 가상 메모리 공간에 액세스하도록 제한됩니다. 또한, 사용자 랜드 코드의 실행이 허용되는 명령어는 CPU가 지원하는 명령어의 서브 세트입니다. 몇 가지 I/O, 인터럽트 및 가상화 관련 지침은 금지 된 코드의 예입니다. 그것들은 권한이있는 명령어로 알려져 있으며 CPU 아키텍처에 따라 하위 링 또는 감독자 모드에 있어야합니다.

Answer 2

인라인 할 수 있습니다. syscall(2)을 통해 직접 시스템 호출을 할 수 있지만 곧 망가질 것입니다. 시스템 호출 오버 헤드 (컨텍스트 스위치 앞뒤로, 커널 체크, ...)는 시스템 호출 자체가 걸리는 시간은 말할 것도없고 노이즈에 인라이닝을 사용하여 이득을 얻습니다. 더 많은 코드는 캐시가 그리 유용하지 않고 성능이 저하됨을 의미합니다. libc/kernel을 믿고 그 문제를 연구하고 (실제로 *.h 파일에서) 뒤에서 당신을 위해 인라인을 수행하십시오.