터미널에 ls라고 치는 순간, 컴퓨터 안에서는 실제로 무슨 일이 벌어질까요? 겉보기엔 아주 단순합니다. 명령어 하나를 입력했을 뿐인데 금세 파일 목록이 쏟아져 나오니까요. 하지만 커널의 관점에서 보면 이는 꽤 거대한 스케일의 이벤트입니다.

프로그램은 디스크에 고이 잠들어 있는 정적인 실행 파일(예: /bin/ls)입니다. 반면 프로세스는 그 프로그램이 메모리에 적재되어 살아 숨 쉬는 동적인 상태를 의미합니다. 이번 장의 핵심 주제는 바로 디스크 속 실행 파일이 어떻게 커널에 의해 온전한 '실행 문맥(Execution Context)'을 갖춘 새로운 프로세스로 깨어나는가에 대한 이야기입니다.

이번 장에서는 크게 여섯 가지 파트를 다룹니다. 커널이 실행 문맥을 어떻게 탈바꿈시키는지, 프로세스의 보안 권한(UID·EUID·setuid·capability), 명령행 인자와 환경 변수가 전달되는 방식, 복잡한 메모리 영역의 배치(text·data·bss·heap·stack), 디버거가 남의 프로세스를 엿보는 원리(ptrace), 그리고 대망의 ELF 파일 형식과 execve() 시스템 콜의 내부 동작까지 살펴볼 것입니다.

사용자가 ls를 입력하면, 셸은 PATH 환경 변수를 뒤져 /bin/ls라는 파일을 찾아냅니다. 그런 다음 셸은 보통 fork()를 호출해 자신과 똑같이 생긴 자식 프로세스를 하나 낳습니다. 여기까지 자식은 부모인 셸과 완벽히 동일한 상태입니다.

이후 자식 프로세스가 execve("/bin/ls", argv, envp)를 호출하면, 커널의 sys_execve()가 개입합니다. 커널은 해당 경로의 파일이 진짜 존재하는지, 실행할 권한은 있는지, 어떤 형태의 실행 파일(ELF인지, 쉘 스크립트인지)인지 꼼꼼히 확인한 후, 기존 셸의 문맥을 밀어버리고 /bin/ls의 세계로 문맥을 재구성합니다.

멀티유저 시스템에서 가장 민감한 질문은 "이 프로세스가 과연 이 행동을 할 자격이 있는가?"입니다. 리눅스는 프로세스마다 꼬리표처럼 credentials(권한 정보)를 달아둡니다. 파일 시스템의 VFS는 파일의 소유자/권한 비트와 프로세스의 이 꼬리표를 대조하여 접근 허용 여부를 결정합니다.

여기서 중요한 것은 'Real ID'와 'Effective ID'의 차이입니다. 대표적인 예가 바로 /usr/bin/passwd입니다. 일반 사용자는 /etc/shadow 같은 중요한 비밀번호 파일을 함부로 수정할 수 없습니다. 그런데 passwd 실행 파일에는 특별한 'setuid' 비트가 켜져 있고 소유자는 root로 되어 있습니다. 따라서 일반 사용자가 이 프로그램을 실행하는 순간, 프로세스의 euid가 일시적으로 파일 소유자인 root로 승격됩니다. 덕분에 자신의 비밀번호를 안전하게 변경할 수 있는 것이죠.

전통적인 유닉스 권한 모델은 'root인가, 아닌가'의 흑백논리로 아주 단순합니다. 하지만 이 모델은 너무 투박하죠. 어떤 웹 서버 프로그램이 80번 포트를 열기 위해 권한이 필요할 뿐인데, 전통적 모델에서는 어쩔 수 없이 무소불위의 root 권한을 쥐여주어야 합니다. 만약 이 프로그램이 해킹당하면 시스템 전체가 넘어가게 됩니다. 이를 막기 위해 도입된 정교한 개념이 바로 capability입니다.

핵심은 간단합니다. "왕(root)의 왕관을 수십 개의 작은 보석(열쇠)으로 쪼개자"는 것입니다. 프로그램에 딱 필요한 보석 하나만 쥐여주면, 버그가 터지더라도 그 피해 범위가 해당 열쇠의 권한 밖으로 벗어나지 못합니다. 커널은 특정 특권 작업 직전에 capable() 함수를 호출해 프로세스가 해당 열쇠를 쥐고 있는지 검사합니다.

리눅스 커널 2.6부터 도입된 Linux Security Modules(LSM)는 커널의 보안 아키텍처를 완전히 뒤바꿔 놓았습니다. LSM의 핵심은 커널 내부의 중요한 길목마다 '보안 정책을 판단할 수 있는 톨게이트(Hook)'를 마련해 두고, 실제 어떤 잣대로 검사할지는 외부 모듈(SELinux, AppArmor 등)이 교체할 수 있도록 플러그인 형태로 만든 것입니다.

여기서 핵심 역할을 하는 것이 바로 security hook입니다. 파일에 접근하려 하거나, 네트워크 소켓을 열거나, 시스템 시간을 변경하려는 아슬아슬한 순간, 커널은 동작을 잠시 멈추고 해당 훅을 호출하여 "이 작업을 허용해도 좋습니까?"라고 보안 모듈에 묻습니다.

예를 들어 stime() 시스템 콜이 실행되면 내부적으로 settime security hook이 불립니다. 기본 모델(dummy)이라면 프로세스의 CAP_SYS_TIME 소유 여부만 묻고 통과시킵니다. 하지만 SELinux 같은 강력한 모듈이 로드되어 있다면, 해당 프로세스의 도메인과 대상 객체의 타입까지 깐깐하게 대조하여 허가증을 발급합니다.

ls -l /usr/bin을 실행할 때, 주인공인 /bin/ls에게 -l과 /usr/bin이라는 지시사항을 어떻게 전달할까요? 우리가 작성하는 C 프로그램의 main(int argc, char *argv[])가 바로 이 지시사항을 건네받는 창구입니다. 위 명령에서 argc는 3, argv[0]은 "ls", argv[1]은 "-l", argv[2]는 "/usr/bin"이 되며, 배열의 끝은 깔끔하게 NULL 포인터로 마감됩니다.

프로그램이 구동되는 백그라운드 환경 변수 역시 main(int argc, char *argv[], char *envp[])를 통해 전달됩니다. envp는 HOME=/home/user나 PATH=/usr/bin:/bin 같은 KEY=VALUE 형태의 문자열 포인터들을 담고 있는 배열이며, 이 역시 끝은 NULL로 장식됩니다.

커널의 메모리 디스크립터(mm_struct)는 arg_start, env_start 등의 필드를 통해 이 문자열들이 메모리 어디에 박혀 있는지 정확히 추적합니다. x86 아키텍처 기준으로 이 데이터들은 사용자 모드 스택의 가장 높은 주소 영역에 자리 잡으며, 스택 자체는 그 아래를 향해(낮은 주소 쪽으로) 자라나게 됩니다.

단순히 return 0;만 수행하는 빈 C 프로그램조차도 실행을 준비하는 시작 코드(startup code)와 종료를 수습하는 뒷정리 코드가 반드시 필요합니다. 즉, 우리가 짠 핵심 로직 외에도 프로그램을 굴러가게 만드는 무수히 많은 '접착제 코드'와 라이브러리가 뒤에 숨어 있습니다.

컴파일러가 만들어낸 오브젝트 파일(.o) 안에는 기계어가 들어있지만, printf처럼 외부 라이브러리에 있는 함수의 실제 메모리 주소는 아직 텅 비어 있습니다. 흩어진 조각들을 하나로 끌어모아 이 구멍 난 주소들을 꿰매주는 녀석이 바로 링커(Linker)입니다.

현대 OS가 사랑하는 동적 링크(공유 라이브러리)의 궁극적인 무기는 압도적인 메모리 절약입니다. 메모리 매핑 기술을 활용하면 libc.so를 100개의 프로세스가 쓰더라도 물리 메모리에는 단 한 벌의 읽기 전용 텍스트(코드) 영역만 올려두고 모두가 이를 공유하게 만들 수 있습니다.

전통적으로 유닉스 프로그래머들은 프로세스의 가상 메모리 공간을 몇 개의 깔끔한 세그먼트(Segment)로 나누어 머릿속에 그립니다.

하지만 현대 운영체제의 주소 공간을 단순히 text, data, bss, stack이라는 네 가지 구역으로만 이해하기에는 부족합니다. mmap을 통한 파일 메모리 매핑, 익명 매핑, 수많은 공유 라이브러리들이 뒤섞이면서, 프로세스의 주소 공간은 거대한 연속된 덩어리가 아니라 파편화된 수많은 메모리 영역(Memory Region)들의 모자이크가 되었습니다. 내 프로그램의 text/data뿐 아니라, libc.so의 text/data, 동적 링커의 text/data, 심지어 커널과 통신하는 vsyscall 페이지까지 복잡하게 공존합니다.

32비트 x86 아키텍처에서 사용자 공간으로 3GB가 주어졌다고 칩시다. 전형적인 ELF 바이너리의 text 구역은 보통 0x08048000이라는 꽤 낮은 주소에서 출발합니다. 그 뒤를 data, bss, heap이 차례로 따르며 위로 자라나고, 반대편 천장인 0xc0000000 근방에서는 사용자 스택이 바닥을 향해 거꾸로 자라 내려옵니다.

이 영리한 flexible layout을 사용하려면 운영체제가 스택이 최대 어디까지 내려올지(RLIMIT_STACK) 미리 알고 있어야 안전거리를 확보할 수 있습니다. 내가 짠 프로그램이 메모리를 어떻게 썰어서 쓰고 있는지 궁금하다면 터미널에서 cat /proc/self/maps를 쳐보세요. 시작 주소, 끝 주소, rwx 권한, 매핑된 파일 이름까지 적나라한 주소 공간의 민낯을 구경할 수 있습니다.

우리가 자주 사용하는 gdb 같은 디버거가 코드를 한 줄씩 멈춰가며 실행하고, 실시간으로 변수를 훔쳐보고 조작할 수 있는 마법의 근원은 무엇일까요? 바로 커널이 제공하는 ptrace()라는 무시무시한 시스템 콜 덕분입니다.

ptrace()는 말 그대로 한 프로세스(디버거)가 다른 프로세스(타겟)의 멱살을 잡고 실행 흐름을 완벽히 통제할 수 있게 해주는 기능입니다. 너무 강력하기 때문에 원칙적으로 나와 소유자가 같은 프로세스만 엿볼 수 있으며, 남의 프로세스를 디버깅하려면 CAP_SYS_PTRACE라는 특수한 권한이 필요합니다. 또한 한 프로세스는 오직 한 명의 추적자에게만 지배당할 수 있습니다.

ptrace()로 묶이는 순간, 타겟 프로세스의 가짜 부모(parent)가 디버거로 바뀝니다. 명령어 한 줄이 끝날 때마다, 혹은 시스템 콜이 불릴 때마다 타겟은 얼음(멈춤) 상태가 되고 가짜 부모인 디버거에게 SIGCHLD 시그널이 날아가 상황을 보고합니다.

리눅스 생태계를 지배하는 표준 실행 파일 포맷은 단연 ELF(Executable and Linking Format)입니다. 과거 유닉스 초창기의 a.out 형식을 밀어내고 사실상의 지배자가 되었죠. 하지만 놀랍게도 리눅스는 커널 차원에서 ELF 외에도 수많은 파일 형식을 품을 수 있도록 설계되어 있습니다.

커널은 자신이 지원할 수 있는 포맷 목록(linux_binfmt 객체들)을 연결 리스트로 가지고 있습니다. 셸 스크립트나 파이썬 파일의 맨 윗줄에 적힌 #!/bin/bash(shebang)도 커널의 인터프리터 포맷 핸들러가 인식하여, 스크립트 대신 지정된 인터프리터를 실행하게끔 방향을 틀어줍니다.

나아가 binfmt_misc는 사용자가 원하는 커스텀 실행 형식을 커널에 직접 등록할 수 있게 해주는 아주 훌륭한 확장 기능입니다. 예를 들어 "파일 맨 앞의 매직 넘버가 'MZ'로 시작하는 윈도우용 exe 파일이면, 묻지도 따지지도 말고 /usr/bin/wine을 실행해서 넘겨줘"라는 식의 영리한 연결이 가능합니다.

리눅스는 기계어 아키텍처(예: x86)만 같다면, 다른 운영체제용으로 컴파일된 이기종 바이너리도 실행할 수 있는 놀라운 유연성을 제공합니다. 이를 지원하는 방법은 크게 두 갈래로 나뉩니다.

커널은 이를 관리하기 위해 execution domain이라는 개념을 도입했습니다. 프로세스는 자신의 personality 값을 조작해 "나는 지금부터 32비트 환경에 있다고 믿을래(PER_LINUX32)"라거나 "나는 SVR4 유닉스 시스템의 관습을 따를래"라고 커널에 선언할 수 있습니다.

유닉스 환경에는 execl(), execvp(), execve() 등 다채로운 exec 함수 패밀리가 존재합니다. 이들은 모두 현재의 프로세스 문맥을 지우고 새 파일을 덮어씌운다는 본질적인 목적은 같지만, 프로그래머가 인자를 던져주는 스타일의 차이일 뿐입니다.

여기서 중요한 커널의 비밀이 하나 있습니다. 리눅스 커널이 실제로 제공하는 시스템 콜은 오직 execve() 단 하나뿐이라는 사실입니다. 나머지 모든 함수들은 C 표준 라이브러리(glibc)가 프로그래머의 편의를 위해 포장해 놓은 래퍼(Wrapper)에 불과합니다. 결국 내부적으로는 모두 인자를 다듬어 execve()를 호출하게 됩니다.

sys_execve() 시스템 콜이 호출되면, 유저 공간의 데이터를 안전한 커널 공간으로 복사해온 뒤 핵심 코어 로직인 do_execve()로 바통을 넘깁니다. 전반부는 철저한 조사와 세팅의 과정입니다.

파일의 맨 앞 128바이트가 핵심인 이유는 바로 거기에 '내가 어떤 포맷이다'라는 매직 넘버(예: ELF의 \x7fELF)가 박혀 있기 때문입니다. 이 앞부분을 읽지 않고서는 이 파일이 윈도우용인지, 스크립트인지, 리눅스 바이너리인지 판단할 길이 없습니다.

알맞은 형식의 load_binary 모듈(예: ELF 핸들러)이 호출되면, 헤더를 파싱해 텍스트와 데이터가 어느 주소에 매핑되어야 하는지, 동적 링커(ld.so)가 필요한지 파악합니다. 그리고 대망의 flush_old_exec()를 호출합니다.

이 순간이 바로 루비콘강을 건너는 '되돌아갈 수 없는 지점(Point of No Return)'입니다. 이 강을 건너고 나면, 설령 이후 단계에서 에러가 발생하더라도 이전 셸 상태로 절대 돌아갈 수 없습니다. 이미 다 부숴버렸기 때문이죠.

깔끔하게 철거가 끝난 공터에 이제 새 건물을 올립니다.

드디어 execve() 시스템 콜이 끝났습니다! 새로운 text, bss, stack이 깔렸으니 이제 곧바로 main() 함수가 실행될까요? 동적 링크로 컴파일된 프로그램이라면 대답은 '아니요'입니다.

커널이 방금 설정해 둔 eip는 main()이 아니라 동적 링커(dynamic linker)의 진입점을 가리키고 있습니다. 유저 모드로 돌아오면 가장 먼저 링커 코드가 깨어나 뒷정리를 시작합니다.

반면 정적 링크 프로그램의 경우는 훨씬 단순하게 흘러갑니다. 외부 라이브러리에 빚진 것이 없으니 이 복잡한 동적 링커 단계를 거칠 필요가 없습니다. 커널이 곧바로 eip를 타겟 프로그램의 main()으로 꽂아주어 실행이 즉시 시작됩니다.