사용자 프로그램은 어떻게 디스크를 읽고, 파일을 쓰며, 프로세스를 생성하고, 메모리를 할당받을 수 있을까요?

만약 모든 프로그램이 하드웨어를 직접 제어한다면, 악의적이거나 버그가 있는 프로그램 하나가 메모리 전체를 훼손하거나 디스크를 망가뜨릴 수 있습니다. 그래서 운영체제는 '커널'이라는 권한 있는 관리자 층을 둡니다. 사용자 모드는 권한이 제한된 공간이고, 커널 모드는 하드웨어와 핵심 자원에 온전히 접근할 수 있는 특권 공간입니다. 시스템 호출(System Call)은 철저히 분리된 이 두 세계를 잇는 유일하고 안전한 통로입니다.

프로그램 코드에서 open(), write(), fork()를 호출할 때 이를 흔히 '시스템 호출'이라고 부르지만, API와 실제 커널 요청은 엄밀히 구분해야 합니다. API는 어떤 서비스를 어떻게 요청해야 하는지 정의한 '인터페이스'이고, 시스템 호출은 소프트웨어 인터럽트나 전용 명령어를 통해 커널에 명시적으로 작업을 요청하는 '행위' 자체를 뜻합니다.

POSIX 표준은 "커널의 내부 구현 방식"이 아니라 응용 프로그램이 사용할 "API"를 규정합니다. 따라서 POSIX를 준수하는 운영체제라 하더라도 내부 구조가 반드시 Linux와 동일할 필요는 없습니다. 응용 프로그램이 기대하는 함수 시그니처와 반환값의 의미만 올바르게 제공하면 됩니다.

사용자 프로그램이 시스템 호출을 실행하면 CPU는 즉시 커널 모드로 전환됩니다. 이때 수백 개의 시스템 호출 중 어떤 작업을 원하는지는 시스템 호출 번호를 통해 전달합니다. x86 아키텍처에서는 이 식별 번호를 eax 레지스터에 담습니다.

커널 메모리에는 sys_call_table이라는 디스패치 배열이 있습니다. 이 배열의 n번째 항목에는 시스템 호출 번호 n에 해당하는 서비스 루틴의 메모리 주소가 저장되어 있습니다. eax 값이 n이면 커널은 sys_call_table[n]을 참조하여 해당 루틴을 호출합니다. 만약 아직 구현되지 않은 번호가 전달되면, 기본적으로 sys_ni_syscall()이 호출되어 -ENOSYS 오류를 반환합니다.

x86 리눅스 환경에서 사용자 모드에서 커널 모드로 넘어가는 방법은 크게 두 가지로 나뉩니다.

모든 하드웨어가 sysenter를 지원하는 것은 아니며, 구버전의 라이브러리들은 여전히 int $0x80을 기본으로 사용합니다. 리눅스 커널은 vsyscall page라는 메커니즘을 통해 현재 구동 중인 하드웨어 환경에 가장 최적화된 방식을 동적으로 자동 선택합니다.

사용자 프로그램이 int $0x80 명령을 실행하면, CPU는 인터럽트 디스크립터 테이블(IDT)에서 128번 벡터를 조회합니다. 커널은 부팅 초기화 단계인 trap_init() 함수에서 set_system_gate(0x80, &system_call)를 호출하여 이 경로를 미리 세팅해 둡니다.

서비스 루틴의 작업이 완료되었다고 해서 곧바로 사용자 프로그램으로 돌아가는 것은 아닙니다. 커널은 제어권을 넘겨주기 직전에 "돌아가기 전에 추가로 처리해야 할 시스템 작업이 있는지" 꼼꼼히 살핍니다.

sysenter 명령어는 메모리 접근 오버헤드를 줄이기 위해 CPU 내부에 있는 세 개의 특수 레지스터(MSR: Model-Specific Register)를 적극 활용합니다.

운영체제가 부팅될 때 각 CPU 코어는 enable_sep_cpu() 함수를 통해 이 MSR 값들을 초기화합니다. sysenter는 하드웨어 인터럽트 방식보다 실행 사이클이 짧아 빠르지만, int $0x80 명령이 자동으로 스택에 푸시해주던 사용자 세그먼트 레지스터, 스택 포인터, EFLAGS, 복귀 주소(EIP) 등을 커널 진입 코드가 일일이 소프트웨어적으로 구성해야 하는 트레이드오프가 있습니다.

C 표준 라이브러리(libc)는 가능하면 빠른 sysenter를 사용하고 싶어 하지만, 코드가 실행되는 현재 CPU나 커널이 이를 지원하지 않을 수도 있습니다. 이를 해결하기 위해 커널은 초기화 과정인 sysenter_setup()에서 특별한 메모리 페이지(vsyscall page)를 하나 준비해 둡니다. 그리고 새로운 ELF 실행 파일이 메모리에 로드될 때, 이 페이지를 각 프로세스의 주소 공간 상단에 동적으로 매핑해 줍니다.

서비스 루틴이 작업을 성공적으로 마치고 반환되었을 때, 지연된 처리 플래그가 없다면 커널은 iret 대신 전용 명령어인 sysexit을 이용해 사용자 모드로의 가장 빠른 복귀를 시도합니다.

sysexit 명령이 CPU에서 실행되면, 하드웨어는 SYSENTER_CS_MSR+16 공식에 따라 사용자 코드 세그먼트 권한을 복원하고, edx 값을 eip에 밀어 넣습니다. 이와 동시에 SYSENTER_CS_MSR+24로 사용자 데이터 세그먼트를 셋업하며 ecx 값을 스택 포인터 esp로 복구한 뒤 사용자 모드로 완전히 돌아갑니다. 이제 제어권은 앞서 언급한 vsyscall page 영역 내의 SYSENTER_RETURN 코드로 떨어집니다.

SYSENTER_RETURN 코드 조각의 임무는 매우 단순하고 명료합니다 — 앞서 __kernel_vsyscall()이 커널로 뛰어들기 직전 사용자 스택 최상단에 푸시해두었던 ebp, edx, ecx 레지스터 값을 하나씩 팝(pop)하여 원래 상태로 복원하고, 최종적으로 ret 명령을 실행하여 이 모든 절차를 트리거했던 libc 래퍼 함수로 부드럽게 제어 흐름을 반환합니다.

주의: 시그널 처리나 스케줄링 등 잔여 작업 플래그가 하나라도 켜져 있다면, 커널은 이 고속 복귀 경로를 과감히 포기하고 공통된 느린 경로(Slow Path)로 빠져 전통적인 iret 명령어를 이용해 안전하게 돌아갑니다. 빠른 길은 환경이 완벽히 깨끗할 때만 허용됩니다.

시스템 호출은 어떤 작업을 할지 알려주는 번호만으로는 부족합니다. write(fd, buf, count)처럼 어느 파일에, 어떤 데이터를, 얼만큼 쓸지 명시하는 구체적인 인자가 필수적입니다. x86 시스템에서는 속도 최적화를 위해 메모리에 기반한 사용자 스택 대신 CPU 레지스터에 인자를 직접 담아 커널에 전달하는 방식을 채택합니다.

이 규약에 따라 최대 6개의 인자까지 레지스터만으로 넘길 수 있습니다. 만약 함수가 6개 이상의 인자를 요구하거나 전달해야 할 데이터가 거대한 구조체라면, 사용자 주소 공간 내의 구조체가 위치한 메모리 포인터 하나만을 레지스터에 담아 넘기는 간접 참조(우회) 방식을 활용합니다. 커널 진입 단계에서 SAVE_ALL 매크로가 이 레지스터들을 커널 스택에 차례대로 푸시해 놓으면, 이후 실행되는 C 언어 기반의 서비스 루틴은 이 스택 레이아웃을 바탕으로 일반적인 함수 인자를 읽듯 자연스럽게 값에 접근할 수 있습니다.

특수한 상황 — 예를 들어, fork() 계열 시스템 호출처럼 자식 프로세스 생성을 위해 부모의 전체 레지스터 컨텍스트를 완벽히 복제해야 하는 서비스 루틴의 경우 — 일반 변수가 아닌 pt_regs 구조체 포인터 타입의 인자를 선언하여, SAVE_ALL이 구성해 둔 레지스터 저장 영역에 직접적이고 광범위하게 접근합니다.

사용자가 악의적이거나 실수로 커널 내부 주소를 포인터 인자로 넘겼을 때, 커널이 이를 의심 없이 읽거나 쓰려고 한다면 시스템 핵심 메모리가 통째로 유출되거나 치명적으로 훼손될 수 있습니다. 따라서 커널은 사용자 공간에서 넘어온 모든 주소의 안전성을 철저히 검사해야만 합니다.

access_ok(type, addr, size) 매크로 함수의 주된 역할은 addr+size 연산 과정에서 정수 오버플로가 발생하지 않는지, 그리고 그 덧셈의 최종 주소가 thread_info.addr_limit.seg 값을 침범하지 않는지 논리적으로 확인하는 것입니다. 일반적인 응용 프로세스의 addr_limit.seg 값은 커널 시작점인 PAGE_OFFSET과 일치합니다. 예외적으로 커널 내부에서 사용자 API를 직접 에뮬레이션해야 할 때는 get_fs나 set_fs 매크로를 사용해 이 상한선을 임시로 재조정하기도 합니다.

대부분의 커널 서비스 루틴은 사용자 공간에 마련된 데이터 버퍼를 빈번하게 읽고 씁니다. 커널 코드는 보안 원칙상 아무리 사용자 포인터라 할지라도 일반적인 C 언어 포인터 다루듯 *ptr = value 형태로 직접 역참조(Dereferencing)해서는 안 되며, 반드시 커널이 제공하는 래핑된 전용 함수나 매크로를 통과해야 합니다.

가끔 커널 코드를 보다 보면 함수 이름 맨 앞에 밑줄 두 개가 연달아 붙은 특별한 변형판(예: __get_user, __copy_from_user)을 마주칠 수 있습니다. 이 함수들은 상위 로직에서 access_ok()를 통한 주소 거친 검증이 이미 확실하게 수행되었다고 전제하여, 함수 내부의 중복된 주소 검사 루틴을 과감히 생략합니다. 이는 오버헤드를 극단적으로 줄이려는 최적화 기법입니다.

앞서 설명한 access_ok() 함수는 PAGE_OFFSET 기반의 매우 1차원적인 범위 검사만 수행할 뿐입니다. 주소값이 PAGE_OFFSET보다 낮더라도, 실제로 해당 영역에 물리 메모리 프레임이 할당(매핑)되어 있지 않은 허공의 주소라면 어떻게 될까요? 커널이 그곳에 손을 뻗는 순간 얄짤없이 하드웨어 페이지 폴트(Page Fault) 예외가 터져 나옵니다. 하지만 명심할 것은, 커널 모드에서 발생한 페이지 폴트가 무조건적으로 "커널을 짜놓은 개발자의 치명적인 멍청한 버그(Oops)"를 의미하지는 않는다는 점입니다.

일반 응용 프로그램과 달리, 커널 모드 영역에서 동작하는 커널 스레드(Kernel Thread) 데몬들은 덩치가 큰 외부 라이브러리인 libc의 래퍼 함수들을 가져다 쓸 수 없습니다. 이런 제약을 해결하기 위해 리눅스 커널 소스 트리는 필요한 시스템 호출 래퍼 루틴을 인라인 어셈블리로 아주 손쉽게 찍어내듯 선언할 수 있는 _syscall0부터 _syscall6까지의 매직 매크로 세트를 기본으로 제공합니다. 매크로 이름 뒤에 붙은 숫자는 시스템 호출 번호 자체를 제외한, 함수가 요구하는 순수 '인자의 개수'를 직관적으로 나타냅니다.

이제 지금까지 흩어져 있던 조각들을 모아, write() 함수가 호출되는 순간부터 끝날 때까지의 웅장한 왕복 여정을 하나의 서사시로 이어보겠습니다.