시스템 콜(System Call) 레퍼런스 (System Call Reference)

x86_64 Linux 시스템 콜 전체 목록을 13개 카테고리(파일 I/O, 프로세스(Process), 메모리, 네트워크, 시그널, IPC, 시간, 보안, 비동기 I/O 등)로 정리합니다. 각 시스콜은 레지스터(Register) 기반 호출 규약(Calling Convention)으로 전달되며, 어셈블리(Assembly)에서 직접 호출하거나 glibc 래퍼로 접근할 수 있고 실시간(Real-time) 관련 제어 시스콜도 포함됩니다. 각 항목마다 syscall 번호, 이름, C 함수 시그니처, 한국어 설명을 제공하여 빠른 조회가 가능합니다. 동작 원리와 진입 경로는 시스템 콜 (System Call) 문서를 참고하세요.

개요

사용자 프로그램은 CPU의 특권 링 3(링 3, Ring 3)에서 실행되며 하드웨어·메모리·파일 등 운영체제 자원에 직접 접근할 수 없습니다. 커널은 이러한 자원을 보호하고 여러 프로세스 간 안전한 공유를 위해 특권 링 0(링 0, Ring 0)에서 실행됩니다. 시스템 콜(System Call)은 사용자 공간에서 커널 서비스를 요청하는 유일하게 허가된 경계 통과 방법입니다 — 사용자 프로그램이 링 3에서 링 0 기능이 필요할 때마다 SYSCALL 명령어를 통해 커널에 요청하고, 커널이 검증 후 처리한 뒤 SYSRET으로 복귀합니다. 동작 원리의 상세 설명은 시스템 콜 (System Call)을 참고하세요.

x86_64 Linux 커널에는 471개 이상의 시스템 콜이 정의되어 있습니다. 2026년 4월 21일 기준 최신 mainline인 Linux 7.0에서는 번호 471까지 할당되어 있으며, rseq_slice_yield도 이미 테이블에 포함되어 있습니다. 6.11부터 일반 syscall 번호는 scripts/syscall.tbl 단일 파일로 관리되고, 각 아키텍처 arch/*/kernel/Makefile.syscalls가 이 표의 abis 필드를 읽어 테이블·헤더를 생성합니다. 아래 카테고리별 분포와 호출 규약을 참고하세요.

주요 errno 오류 코드 참조

syscall이 실패하면 커널은 -errno를 rax로 반환하고, glibc 래퍼가 errno 전역 변수에 양수 값을 설정한 뒤 -1을 반환합니다.

syscall 기초 용어 정리

파일 I/O

모든 사용자 데이터는 결국 파일을 통해 저장·전송됩니다. Linux는 모든 것이 파일(Everything is a file) 철학을 따르므로 일반 파일뿐 아니라 소켓·파이프·디바이스·/proc 가상 파일 모두 동일한 read()/write() 인터페이스로 접근합니다. read()/write() 호출은 커널 내부에서 VFS → 페이지 캐시(Page Cache) → 파일시스템 드라이버 순으로 처리됩니다. 자세한 VFS 경로는 VFS 계층을 참고하세요.

open() / openat() 플래그 (flags 인자)

기본 파일 I/O 패턴

/* open → read → write → close 기본 패턴 */
int fd = openat(AT_FDCWD, "file.txt", O_RDONLY | O_CLOEXEC);
if (fd < 0) { perror("openat"); exit(1); }

char buf[4096];
ssize_t n;
while ((n = read(fd, buf, sizeof(buf))) > 0) {
    /* 부분 쓰기 처리: write는 요청보다 적게 쓸 수 있음 */
    ssize_t written = 0;
    while (written < n) {
        ssize_t w = write(STDOUT_FILENO, buf + written, n - written);
        if (w < 0) { perror("write"); break; }
        written += w;
    }
}
if (n < 0) perror("read");
close(fd);   /* EINTR에도 fd는 닫혀있으므로 재시도 금지 */

/* sendfile: 파일 → 소켓 zero-copy */
off_t off = 0;
sendfile(sock_fd, file_fd, &off, file_size);

/* pread/pwrite: 멀티스레드에서 안전한 위치 지정 I/O */
ssize_t r = pread64(fd, buf, 512, offset);  /* lseek 불필요 */

write() 커널 내부 경로

파일 디스크립터 관리

파일 디스크립터(fd)는 단순한 정수이지만, 그 뒤에는 커널 내부의 복잡한 자료구조 계층이 있습니다: fd → struct file(파일 오프셋·플래그·참조 카운트) → struct inode(메타데이터·실제 데이터 위치) → 블록 장치(Block Device). 프로세스마다 고유한 fd 테이블을 가지며 0(stdin), 1(stdout), 2(stderr)는 기본 할당됩니다. fd 관리 syscall을 이해하면 셸 리다이렉션(2>&1은 내부에서 dup2(2, 1)), 파이프라인(Pipeline)(pipe() 후 자식에서 dup2()), fd 누수(Leak) 방지(O_CLOEXEC로 exec 시 자동 닫기), 멀티스레드 안전 복제(dup3·F_DUPFD_CLOEXEC의 원자적 처리)를 올바르게 구현할 수 있습니다. fork() 시 fd 테이블이 복사되고, execve() 시 O_CLOEXEC 설정된 fd는 자동으로 닫힙니다.

fcntl() 주요 명령 (cmd 인자)

디렉터리 & 파일시스템

파일시스템(Filesystem)은 파일과 디렉터리의 계층 구조를 디스크에 저장하고 조회하는 방법을 정의합니다. Linux는 VFS(Virtual File System) 추상화 계층을 통해 ext4·Btrfs·XFS·NFS 등 다양한 파일시스템을 단일 인터페이스로 지원합니다. 디렉터리 항목(dentry)은 파일 이름과 inode 번호의 매핑이며, 하드 링크(Hard Link)는 같은 inode를 가리키는 여러 이름, 심볼릭 링크(Symbolic Link)는 다른 경로를 가리키는 파일입니다. 경로 기반 syscall보다 *at() 변형(openat, linkat, mkdirat, renameat2 등)이 TOCTOU 경쟁 조건(Race Condition)을 방지하고 O_CLOEXEC를 원자적으로 설정할 수 있어 보안이 중요한 코드에서 권장됩니다. 마운트(Mount)는 특정 디렉터리(마운트 포인트)에 파일시스템을 연결하는 작업으로, CAP_SYS_ADMIN 권한 또는 사용자 네임스페이스가 필요합니다.

하드 링크 vs 심볼릭 링크 비교

mount() 주요 플래그

Linux 6.8부터: statmount()와 listmount()가 추가되어 /proc/<pid>/mountinfo 파싱 없이 마운트 토폴로지를 직접 조회할 수 있습니다. Linux 6.15에서 statmount()에 idmapping 조회 기능과 마운트 토폴로지 변경 알림 API가 추가되었으며, open_tree_attr()로 중첩 idmapped 마운트 생성이 가능해졌습니다.

파일 변경 감시 (inotify)

inotify는 파일시스템 이벤트를 fd 기반으로 모니터링하는 메커니즘입니다. 파일 생성, 삭제, 수정, 이동 등을 감시하며, IDE의 자동 새로고침, 로그 모니터링, 빌드 도구의 파일 감시 등에 사용됩니다.

프로세스 관리

프로세스(Process)는 실행 중인 프로그램의 인스턴스로, 커널이 각 프로세스에게 독립된 가상 주소 공간·파일 디스크립터 테이블·자격증명(Credentials)을 부여하여 서로 격리합니다. 프로그램을 실행하거나 종료하는 행위 자체가 커널 자원을 생성·해제하는 과정이므로 반드시 syscall을 통해 이루어집니다. Linux에서는 프로세스와 스레드(Thread)가 clone()이라는 하나의 syscall로 통합 생성되며, 어떤 자원(메모리 공간, fd 테이블, 시그널 핸들러 등)을 공유할지 플래그로 결정합니다. fork()는 내부적으로 clone(SIGCHLD, ...)와 동일하고, pthread_create()는 clone(CLONE_VM|CLONE_FILES|CLONE_THREAD|...)를 사용합니다.

clone() 주요 플래그 (flags 인자)

fork/exec 기본 패턴

/* fork → exec → wait 기본 패턴 */
pid_t pid = fork();
if (pid < 0) { perror("fork"); exit(1); }
if (pid == 0) {
    /* 자식: 새 프로그램 실행 */
    execve("/usr/bin/ls", (char*[]){"ls", "-la", NULL},
           (char*[]){"PATH=/usr/bin", NULL});
    _exit(127);  /* execve 실패 시 — exit() 아닌 _exit() 사용 */
}
/* 부모: 자식 종료 대기 */
int status;
waitpid(pid, &status, 0);
if (WIFEXITED(status))
    printf("종료 코드: %d\n", WEXITSTATUS(status));

/* 데몬 프로세스 생성 패턴 (POSIX) */
if (fork() > 0) _exit(0);  /* 부모 종료 → init 입양 */
setsid();                       /* 새 세션, 제어 터미널 분리 */
if (fork() > 0) _exit(0);  /* 세션 리더 아닌 프로세스로 */
chdir("/");                   /* 마운트 해제 방지 */
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);

메모리 관리

현대 운영체제는 각 프로세스에게 독립된 가상 주소 공간(Virtual Address Space)을 제공합니다. 프로세스는 물리 메모리(Physical Memory) 주소를 알 필요 없이 가상 주소(Virtual Address)만 사용하고, 커널의 메모리 관리 유닛(MMU)이 페이지 테이블(Page Table)을 통해 가상 → 물리 주소(Physical Address)를 변환합니다. 이 가상 주소 공간을 할당·해제·보호하는 작업이 커널의 핵심 책임이므로 반드시 syscall을 통해 이루어집니다. glibc의 malloc()은 내부적으로 작은 할당(≤128KB)에는 brk()를, 큰 할당에는 mmap(MAP_ANONYMOUS)를 사용하며, 직접 syscall을 호출하지 않고 glibc 메모리 풀을 경유합니다. 파일을 메모리에 매핑(mmap)하면 파일 I/O 없이 포인터 접근만으로 파일 내용을 읽고 쓸 수 있어 데이터베이스·인터프리터 등에서 광범위하게 활용됩니다.

mmap() prot / flags 인자

madvise() 힌트 (advice 인자)

mmap 페이지 폴트(Page Fault) 처리 흐름

mmap 활용 패턴

/* 파일 전체를 메모리 매핑하여 읽기 */
int fd = open("data.bin", O_RDONLY);
struct stat st;
fstat(fd, &st);
void *map = mmap(NULL, st.st_size, PROT_READ,
                  MAP_PRIVATE, fd, 0);
close(fd);  /* fd는 즉시 닫아도 매핑은 유지됨 */
madvise(map, st.st_size, MADV_SEQUENTIAL);
/* map[0] ~ map[st.st_size-1] 직접 접근 가능 */
munmap(map, st.st_size);

/* 익명 mmap: 큰 메모리 할당 (malloc 내부 방식) */
void *big = mmap(NULL, 1 << 20,  /* 1MB */
                  PROT_READ | PROT_WRITE,
                  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

/* 공유 메모리: 프로세스 간 통신 */
int mfd = memfd_create("shm", MFD_CLOEXEC);
ftruncate(mfd, 4096);
void *shared = mmap(NULL, 4096,
    PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0);
/* fork 후 자식과 공유됨, 또는 Unix socket으로 mfd 전달 */

네트워크 소켓

네트워크 통신도 파일 디스크립터(fd) 기반으로 추상화됩니다. socket()이 반환한 fd는 read()/write()로 데이터를 보내고 받을 수 있어 파일 I/O와 같은 인터페이스로 다룰 수 있습니다. 소켓의 핵심 특성인 프로토콜 패밀리(AF_INET=IPv4, AF_INET6=IPv6, AF_UNIX=같은 머신 내 IPC), 타입(SOCK_STREAM=TCP 연결형, SOCK_DGRAM=UDP 비연결형), 프로토콜은 socket()을 생성할 때 결정됩니다. 이후 TCP 서버는 bind → listen → accept, 클라이언트는 connect 순서로 연결을 수립하고, UDP는 connect 없이 sendto/recvfrom을 직접 사용합니다. 소켓 옵션(setsockopt)으로 재사용 허가(SO_REUSEADDR), 버퍼 크기, keep-alive 등을 세밀하게 제어합니다.

socket() domain / type 조합

setsockopt() 주요 옵션

TCP 서버 기본 패턴

/* 최소 TCP 에코 서버 */
int sfd = socket(AF_INET, SOCK_STREAM | SOCK_CLOEXEC, 0);
int on = 1;
setsockopt(sfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

struct sockaddr_in addr = {
    .sin_family = AF_INET,
    .sin_port   = htons(8080),
    .sin_addr   = { .s_addr = INADDR_ANY },
};
bind(sfd, (struct sockaddr *)&addr, sizeof(addr));
listen(sfd, 128);  /* somaxconn이 실제 상한 */

for (;;) {
    int cfd = accept4(sfd, NULL, NULL,
                      SOCK_CLOEXEC | SOCK_NONBLOCK);
    if (cfd < 0) continue;
    /* 실제 서버: epoll에 cfd 등록 후 비동기 처리 */
    char buf[4096];
    ssize_t n = recv(cfd, buf, sizeof(buf), 0);
    if (n > 0) send(cfd, buf, n, MSG_NOSIGNAL);
    close(cfd);
}

시그널

시그널(Signal)은 커널 또는 다른 프로세스가 목표 프로세스에게 특정 이벤트가 발생했음을 알리는 비동기 알림 메커니즘입니다. 예를 들어 Ctrl+C를 누르면 터미널 드라이버가 전경(Foreground) 프로세스 그룹에 SIGINT(2)를 보내고, 자식 프로세스가 종료되면 커널이 부모에게 SIGCHLD(17)를 보냅니다. 각 프로세스는 시그널마다 기본 동작(Default: 종료·무시·중지), 무시(Ignore), 또는 사용자 정의 핸들러(Handler) 세 가지 중 하나를 선택할 수 있습니다. 시그널 전달은 커널이 해당 프로세스를 스케줄링하는 시점(syscall 복귀 직전 또는 인터럽트 복귀 시)에 처리됩니다 — 코드 실행 중 즉각 인터럽트하지 않습니다. SIGKILL(9)과 SIGSTOP(19)은 프로세스가 블록하거나 무시할 수 없으며, 커널이 강제로 처리합니다.

표준 시그널 참조 (x86_64)

시그널 핸들러 등록 패턴

/* 안전한 시그널 핸들러 패턴 */
static volatile sig_atomic_t got_signal = 0;

static void handler(int sig) {
    got_signal = 1;  /* sig_atomic_t만 안전하게 쓸 수 있음 */
}

struct sigaction sa = {
    .sa_handler = handler,
    .sa_flags   = SA_RESTART,  /* 중단된 syscall 자동 재시작 */
};
sigemptyset(&sa.sa_mask);
sigaction(SIGTERM, &sa, NULL);
sigaction(SIGINT,  &sa, NULL);

/* 이벤트 루프에서 시그널 처리 (signalfd 방식) */
sigset_t mask;
sigemptyset(&mask);
sigaddset(&mask, SIGTERM);
sigprocmask(SIG_BLOCK, &mask, NULL);
int sigfd = signalfd(-1, &mask, SFD_NONBLOCK | SFD_CLOEXEC);
/* sigfd를 epoll에 등록하면 이벤트 루프에서 시그널 처리 가능 */

IPC (프로세스 간 통신)

IPC(Inter-Process Communication)는 서로 다른 프로세스 간에 데이터를 교환하거나 실행을 동기화하는 메커니즘입니다. 프로세스는 기본적으로 독립된 가상 주소 공간을 사용하므로 포인터를 직접 공유할 수 없고, 커널이 중개하는 공유 채널이 필요합니다. Linux의 IPC 메커니즘은 특성에 따라 선택합니다: 파이프(pipe)는 부모-자식 간 단방향 스트림, Unix 도메인 소켓은 양방향·권한 전달·fd 공유가 가능한 범용 IPC, 공유 메모리(shared memory)는 대용량 데이터를 복사 없이 교환하는 최고 성능 방법, futex는 잠금 경합(Lock Contention)이 없는 경우 syscall을 생략하는 빠른 동기화 기본 요소입니다. 현대적 설계에서는 futex(잠금), Unix socket(메시지), memfd+mmap(대용량 공유 메모리)을 조합하여 사용합니다.

Linux 6.7부터: futex2 시스템 콜 패밀리(futex_wait, futex_wake(별도 미추가), futex_requeue)가 완성되었습니다. 기존 다중화(Multiplexing)된 futex() 인터페이스의 각 오퍼레이션을 독립 syscall로 분리하여 타입 안전성과 유지보수성을 높입니다. glibc가 래퍼를 제공하기 전까지는 syscall(SYS_futex_wait, ...) 형태로 직접 호출해야 합니다.

IPC 활용 패턴

/* pipe2: 부모-자식 간 스트림 통신 */
int pfd[2];
pipe2(pfd, O_CLOEXEC);
if (fork() == 0) {
    close(pfd[0]);  /* 자식: 읽기 끝 닫기 */
    write(pfd[1], "hello", 5);
    _exit(0);
}
close(pfd[1]);  /* 부모: 쓰기 끝 닫기 */
char buf[64];
read(pfd[0], buf, sizeof(buf));

/* eventfd: 스레드/프로세스 간 이벤트 알림 */
int efd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
/* 생산자: 카운터 증가 */
uint64_t val = 1;
write(efd, &val, sizeof(val));
/* 소비자: 카운터 읽기 (읽으면 0으로 초기화) */
read(efd, &val, sizeof(val));
/* epoll에 efd 등록하면 생산자 알림을 이벤트 루프에서 처리 */

시간 & 타이머

정확한 시간 측정과 타이머 기반 이벤트 처리는 네트워크 프로토콜(타임아웃·재전송(Retransmission)), 실시간 제어(주기 작업), 성능 분석(latency 측정) 등 광범위한 영역에서 필요합니다. Linux는 여러 종류의 시계(Clock)를 제공합니다: CLOCK_REALTIME은 벽시계(Wall Clock) 시간으로 NTP 조정의 영향을 받으며, CLOCK_MONOTONIC은 항상 단조 증가하여 경과 시간 측정에 안전하고, CLOCK_BOOTTIME은 슬립(Sleep) 중에도 계속 흐르며, CLOCK_TAI는 윤초(Leap Second)를 포함한 국제 원자시입니다. clock_gettime과 gettimeofday는 vDSO(virtual Dynamic Shared Object)를 통해 커널 진입 없이 사용자 공간에서 직접 실행되므로 일반 syscall 대비 3~10배 빠릅니다. 고해상도 타이머(hrtimer)가 필요할 때는 CLOCK_MONOTONIC을 우선 사용하세요.

Clock ID 참조

보안 & 권한

Linux 보안 모델은 세 가지 기본 질문으로 구성됩니다: "누구인가"(신원/UID·GID), "무엇을 할 수 있는가"(권한/Capabilities), "무엇에 접근할 수 있는가"(정책/LSM). 전통적인 DAC(Discretionary Access Control)는 파일 소유자·그룹·others 3단계 권한 비트로 접근을 제어합니다. 현대 Linux는 여기에 더해 Capabilities(root 권한을 37개 세분화된 능력으로 분리), LSM(SELinux/AppArmor — 강제적 접근 통제), seccomp(syscall 화이트리스트·BPF 필터로 공격 표면 최소화), Namespaces(PID/user/mount/network 등 자원 격리)를 다층으로 결합합니다. 컨테이너(Docker/Kubernetes)의 격리는 이 네 가지 메커니즘의 조합으로 구현됩니다. 관련 syscall은 프로세스가 자신의 자격증명(Credentials)을 변경하거나 보안 정책을 설정하는 데 사용됩니다.

주요 Linux Capabilities

Linux Namespaces 종류

Linux 6.8부터: lsm_get_self_attr(), lsm_set_self_attr(), lsm_list_modules() 세 가지 LSM syscall이 추가되었습니다. 기존 /proc/self/attr/ 인터페이스는 단일 LSM 시대에 설계되어 다중 LSM 스태킹 환경에서 정보가 누락되는 문제가 있었습니다. 새 syscall은 LSM ID 기반으로 각 모듈의 속성을 명확히 분리합니다.

Landlock 샌드박싱 패턴 (Linux 5.13+)

/* 파일시스템 접근을 /tmp 아래로만 제한 */
struct landlock_ruleset_attr attr = {
    .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE |
                         LANDLOCK_ACCESS_FS_WRITE_FILE,
};
int rfd = landlock_create_ruleset(&attr, sizeof(attr), 0);

/* /tmp 아래만 읽기/쓰기 허용 */
int dir = open("/tmp", O_PATH | O_CLOEXEC);
struct landlock_path_beneath_attr rule = {
    .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE |
                      LANDLOCK_ACCESS_FS_WRITE_FILE,
    .parent_fd = dir,
};
landlock_add_rule(rfd, LANDLOCK_RULE_PATH_BENEATH,
                  &rule, 0);
close(dir);

/* 규칙 적용 (되돌릴 수 없음!) */
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
landlock_restrict_self(rfd, 0);
close(rfd);
/* 이후 /tmp 이외의 파일 접근 시 EACCES */

비동기 I/O & 이벤트

수천~수만 개의 동시 연결을 처리해야 하는 서버(웹 서버, 데이터베이스, 게임 서버)는 각 연결마다 스레드를 만드는 방식으로는 메모리와 문맥 전환(Context Switch) 오버헤드 때문에 확장하기 어렵습니다. 대신 이벤트 기반(Event-Driven) 방식으로 하나의 스레드가 다수의 fd를 감시하며 준비된 fd만 처리합니다. Linux에서 이 역할을 하는 syscall이 epoll입니다 — O(1) 시간에 준비된 fd를 반환하여 select/poll보다 대규모 연결에 효율적입니다. 한 단계 더 나아가 io_uring(Linux 5.1+)은 제출 큐(SQ Ring)와 완료 큐(CQ Ring)를 공유 메모리로 구현하여 I/O 요청과 응답을 syscall 없이 배치로 처리합니다. nginx·libuv·tokio·Redis는 epoll, io_uring이 지원되는 최신 환경에서는 Tokio·Monoio가 io_uring을 활용합니다.

epoll / poll / select / io_uring 비교

io_uring 주요 오퍼레이션 타입 (IORING_OP_*)

epoll 레벨 트리거(LT) vs 엣지 트리거(ET) 비교

epoll 이벤트 루프 패턴

int epfd = epoll_create1(EPOLL_CLOEXEC);

/* 서버 소켓을 epoll에 등록 */
struct epoll_event ev = {
    .events = EPOLLIN,
    .data.fd = server_fd,
};
epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);

struct epoll_event events[1024];
for (;;) {
    int nfds = epoll_wait(epfd, events, 1024, -1);
    for (int i = 0; i < nfds; i++) {
        if (events[i].data.fd == server_fd) {
            /* 새 연결 수락 후 epoll에 등록 */
            int cfd = accept4(server_fd, NULL, NULL,
                              SOCK_NONBLOCK | SOCK_CLOEXEC);
            ev.events = EPOLLIN | EPOLLET;  /* 엣지 트리거 */
            ev.data.fd = cfd;
            epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, &ev);
        } else {
            /* ET 모드: EAGAIN까지 모든 데이터 읽기 필수 */
            for (;;) {
                ssize_t n = read(events[i].data.fd, buf, sizeof(buf));
                if (n <= 0) break;  /* EAGAIN 또는 EOF */
                process_data(buf, n);
            }
        }
    }
}

기타 시스템 콜

앞서 분류된 카테고리에 속하지 않는 중요한 syscall 목록입니다. 시스템 정보 조회(uname, sysinfo), 리소스 제한(prlimit64: 프로세스별 파일 수·메모리·CPU 시간 한도), 커널 모듈 로딩(finit_module), eBPF(bpf(): 커널에 안전하게 검증된 프로그램을 주입하는 혁신적 인터페이스), 성능 분석(perf_event_open(): PMU 하드웨어 카운터·tracepoint 접근)이 여기에 해당합니다. 특히 bpf()는 클래식 BPF(패킷 필터)에서 출발해 현재는 네트워킹(XDP), 보안(seccomp-BPF, BPF-LSM), 관측성(bpftrace, BCC), 스케줄러(sched_ext) 등 커널 전반을 사용자 프로그램이 안전하게 확장하는 플랫폼으로 발전했습니다. prlimit64는 데몬/서버 프로세스의 열린 파일 수(RLIMIT_NOFILE)·잠금 가능 메모리(RLIMIT_MEMLOCK)·코어 덤프 크기(RLIMIT_CORE) 등을 운영 환경에 맞게 튜닝하는 데 필수입니다.

RLIMIT 리소스 종류

eBPF 프로그램 타입 (bpf() 주요 용도)

관련 문서

시스템 콜의 동작 원리와 각 서브시스템 내용을 담은 문서 목록입니다.

참고자료

커널 공식 문서

• Syscall User Dispatch — 사용자 공간에서 시스템 콜을 선택적으로 가로채는 메커니즘을 설명합니다. Wine 등 호환 계층 구현에 활용됩니다.
• Adding a New System Call — 새로운 시스템 콜을 커널에 추가하는 절차와 설계 가이드라인을 다룹니다. 번호 할당, 호환 ABI, 테스트 방법을 포함합니다.
• Seccomp BPF (SECure COMPuting with filters) — BPF 필터를 사용하여 프로세스가 호출할 수 있는 시스템 콜을 제한하는 방법을 설명합니다.
• unshare system call — unshare() 시스템 콜로 네임스페이스를 분리하는 사용법과 clone() 플래그와의 관계를 설명합니다.
• Overview of the Linux Virtual File System — 파일 I/O 시스템 콜이 VFS 계층을 통해 처리되는 내부 구조를 설명합니다.

man 페이지 (Linux Programmer's Manual)

• syscalls(2) — Linux 시스템 콜 전체 목록과 각 콜이 도입된 커널 버전 정보를 제공합니다.
• syscall(2) — 아키텍처별 시스템 콜 호출 규약(레지스터 매핑, 반환값 처리)을 상세히 기술합니다.
• system_data_types(7) — 시스템 콜 시그니처에 사용되는 pid_t, size_t, off_t 등 데이터 타입의 정의와 크기를 설명합니다.
• intro(2) — 시스템 콜 섹션 소개로, 에러 반환 규약(errno)과 공통 에러 코드를 설명합니다.
• vdso(7) — vDSO(virtual Dynamic Shared Object)를 통해 gettimeofday, clock_gettime 등이 커널 진입 없이 실행되는 원리를 설명합니다.
• clone(2) — clone()/clone3()의 플래그 조합과 네임스페이스·cgroup 격리 옵션을 상세히 다룹니다.

아키텍처별 시스템 콜 테이블

• x86_64 syscall 테이블 — x86_64 아키텍처의 시스템 콜 번호, 이름, 진입 함수 매핑 테이블입니다.
• x86 (32비트) syscall 테이블 — i386 호환 모드의 시스템 콜 번호 매핑입니다. x86_64와 번호가 다릅니다.
• asm-generic/unistd.h — ARM64, RISC-V 등 새 아키텍처가 공유하는 제네릭 시스템 콜 번호 정의입니다.
• ARM64 compat (32비트) syscall 정의 — AArch32 호환 모드에서 사용하는 시스템 콜 번호를 정의합니다.

커널 소스 (Bootlin Elixir)

• arch/x86/entry/entry_64.S — x86_64 시스템 콜 진입점(Entry Point, entry_SYSCALL_64)의 어셈블리 구현입니다. SWAPGS, 스택 전환, 레지스터 저장 과정을 확인할 수 있습니다.
• fs/read_write.c — read()/write()/pread64()/pwrite64() 시스템 콜의 커널 구현입니다.
• kernel/fork.c — fork()/clone()/clone3() 시스템 콜의 핵심 구현인 copy_process() 함수를 포함합니다.
• mm/mmap.c — mmap()/munmap()/mprotect() 등 메모리 매핑 시스템 콜의 VMA 처리 구현입니다.
• net/socket.c — socket()/bind()/connect()/accept() 등 소켓 시스템 콜의 진입 함수를 포함합니다.
• kernel/signal.c — kill()/rt_sigaction()/rt_sigprocmask() 등 시그널 시스템 콜의 구현입니다.

LWN.net 기사

• Anatomy of a system call, part 1 (2014) — x86_64에서 시스템 콜이 사용자 공간에서 커널로 진입하는 전체 경로를 단계별로 분석합니다.
• Anatomy of a system call, part 2 (2014) — 시스템 콜 테이블 구성, SYSCALL_DEFINE 매크로(Macro), 호환 계층 처리를 이어서 설명합니다.
• The vDSO on arm64 (2017) — ARM64 아키텍처에서 vDSO 구현과 시스템 콜 오버헤드 절감 방식을 설명합니다.
• clone3(), fchmodat4(), and the obsession with flags (2020) — 새로운 시스템 콜 설계 시 확장 가능한 구조체 인자 방식의 장점을 논의합니다.
• An introduction to Linux kernel syscall auditing (2019) — 시스템 콜 감사(audit) 프레임워크의 동작 원리와 보안 활용을 설명합니다.

외부 참고 자료

• Chromium OS — Linux System Call Table — x86, x86_64, ARM, ARM64, MIPS 아키텍처별 시스템 콜 번호를 비교 정리한 테이블입니다.
• Linux Syscall Reference (Filippo Valsorda) — x86_64 시스템 콜 번호, 이름, 레지스터 매핑을 검색할 수 있는 인터랙티브 테이블입니다.
• The Definitive Guide to Linux System Calls — 시스템 콜의 저수준 동작 원리를 glibc 래퍼부터 커널 진입까지 상세히 설명합니다.