커널 아키텍처 (Kernel Architecture)

리눅스 커널 아키텍처 심층 분석. x86_64, ARM64, RISC-V 아키텍처별 부팅 과정, 주소 공간, 특권 레벨, 커널 소스 트리 구조를 다룹니다.

x86_64, ARM64, RISC-V 아키텍처별 커널 구조, 부팅 과정, 주소 공간 레이아웃을 상세히 다룹니다.

리눅스 커널 개요 (Linux Kernel Overview)

리눅스 커널은 1991년 Linus Torvalds가 처음 공개한 이래, 현재 세계에서 가장 널리 사용되는 운영체제 커널입니다. 서버, 데스크탑, 임베디드 기기, 스마트폰(Android), 슈퍼컴퓨터에 이르기까지 거의 모든 컴퓨팅 영역에서 동작합니다. 커널은 하드웨어와 사용자 공간(user space) 사이에서 추상화 계층 역할을 하며, 다음과 같은 핵심 기능을 담당합니다:

• 프로세스 관리 (Process Management) - 프로세스 생성, 스케줄링, 종료, 시그널 처리
• 메모리 관리 (Memory Management) - 가상 메모리, 페이지 테이블, 물리 메모리 할당
• 파일시스템 (Filesystem) - VFS를 통한 다양한 파일시스템 지원
• 디바이스 드라이버 (Device Drivers) - 하드웨어 추상화 및 제어
• 네트워킹 (Networking) - TCP/IP 스택, 소켓, 패킷 필터링
• 보안 (Security) - LSM, SELinux, capabilities, seccomp

모놀리식 vs 마이크로커널 (Monolithic vs Microkernel)

운영체제 커널 설계에는 크게 두 가지 접근 방식이 있습니다. 모놀리식 커널(Monolithic Kernel)은 모든 핵심 서비스(프로세스 관리, 메모리 관리, 파일시스템, 드라이버 등)가 하나의 커다란 커널 이미지 안에서 동일한 주소 공간(커널 공간)에서 실행됩니다. 반면 마이크로커널(Microkernel)은 최소한의 기능만 커널에 포함하고 나머지는 사용자 공간 서버로 분리합니다.

리눅스는 모놀리식 커널입니다. 그러나 순수한 모놀리식이 아닌, 동적으로 적재 가능한 커널 모듈(Loadable Kernel Module, LKM)을 지원하여 모듈화의 유연성을 확보합니다. 이를 "모듈형 모놀리식(Modular Monolithic)" 커널이라고도 합니다. 커널 모듈에 대한 자세한 내용은 커널 모듈 (Kernel Module) 문서를 참고하세요.

x86_64 아키텍처 (x86_64 Architecture)

x86_64(또는 AMD64, Intel 64)는 데스크탑과 서버 환경에서 가장 널리 사용되는 아키텍처입니다. x86의 32비트 아키텍처를 64비트로 확장한 것으로, 리눅스 커널에서 가장 오랫동안 지원해 온 아키텍처 중 하나입니다.

부팅 과정 (Boot Process)

x86_64 시스템의 부팅 과정은 펌웨어에서 시작하여 커널이 완전히 초기화될 때까지 여러 단계를 거칩니다. 현대 시스템에서는 UEFI가 표준이지만, 레거시 BIOS도 여전히 지원됩니다.

커널의 x86_64 엔트리 포인트는 어셈블리로 작성되어 있습니다. 다음은 핵심 부팅 코드의 간략화된 예시입니다:

/* arch/x86/kernel/head_64.S - x86_64 커널 엔트리 포인트 (간략화) */

SYM_CODE_START_NOALIGN(startup_64)
    /* 세그먼트 레지스터 초기화 */
    xorl    %eax, %eax
    movl    %eax, %ds
    movl    %eax, %es
    movl    %eax, %ss
    movl    %eax, %fs
    movl    %eax, %gs

    /* 초기 페이지 테이블 설정 (Identity mapping) */
    leaq    early_top_pgt(%rip), %rax
    movq    %rax, %cr3

    /* 스택 포인터 설정 */
    leaq    init_thread_union+THREAD_SIZE(%rip), %rsp

    /* C 코드로 점프 */
    call    x86_64_start_kernel
SYM_CODE_END(startup_64)

주소 공간 레이아웃 (Address Space Layout)

x86_64에서는 48비트 가상 주소 공간(256TB)을 사용합니다. 이 공간은 사용자 영역(하위)과 커널 영역(상위)으로 명확하게 분리됩니다. 최신 커널에서는 5-level paging을 통해 57비트(128PB) 주소 공간도 지원합니다. 다음 다이어그램은 4-level paging 기준 주소 공간 레이아웃을 보여줍니다:

아키텍처별 주소 변환 경로 비교

가상 주소를 물리 주소로 변환하는 핵심 경로는 세 아키텍처 모두 유사하지만, 제어 레지스터와 페이지 테이블 포맷이 다릅니다. 아래 다이어그램은 x86_64, ARM64, RISC-V의 변환 경로를 한 화면에서 비교합니다.

세그먼테이션과 페이징 (Segmentation & Paging)

x86_64에서 세그먼테이션은 사실상 flat model로 사용됩니다. 모든 세그먼트의 베이스가 0이고 리미트가 최대값으로 설정되어, 세그먼테이션은 사실상 비활성화된 상태입니다. 그러나 GDT(Global Descriptor Table)는 여전히 존재하며, 커널/사용자 모드 전환과 TSS(Task State Segment)를 위해 필수적입니다.

페이징은 4단계 페이지 테이블을 사용합니다 (5단계 페이징은 CONFIG_X86_5LEVEL=y로 활성화):

• PGD (Page Global Directory) - 512 엔트리, CR3가 가리킴
• PUD (Page Upper Directory) - 512 엔트리
• PMD (Page Middle Directory) - 512 엔트리
• PTE (Page Table Entry) - 512 엔트리, 최종 물리 페이지 매핑

링 구조 (Protection Rings)

x86_64는 4개의 특권 레벨(Ring 0 ~ Ring 3)을 제공하지만, 리눅스에서는 실제로 Ring 0(커널 모드)과 Ring 3(사용자 모드) 두 레벨만 사용합니다. Ring 1과 Ring 2는 사용되지 않으며, 가상화 확장(VT-x)에서는 Ring -1(VMX root mode)이라는 개념이 추가됩니다.

/* arch/x86/include/asm/segment.h - GDT 세그먼트 정의 */

/*
 * x86_64 GDT 레이아웃 (간략화):
 *  Entry 0: NULL 디스크립터 (CPU 요구사항)
 *  Entry 1: Kernel 32-bit Code Segment (호환 모드용)
 *  Entry 2: Kernel 64-bit Code Segment
 *  Entry 3: Kernel Data Segment
 *  Entry 4: User 32-bit Code Segment (ia32 compat)
 *  Entry 5: User Data Segment
 *  Entry 6: User 64-bit Code Segment
 *  Entry 7+: TSS, TLS 등
 */
#define GDT_ENTRY_KERNEL32_CS       1
#define GDT_ENTRY_KERNEL_CS         2
#define GDT_ENTRY_KERNEL_DS         3
#define GDT_ENTRY_DEFAULT_USER32_CS 4
#define GDT_ENTRY_DEFAULT_USER_DS   5
#define GDT_ENTRY_DEFAULT_USER_CS   6

/* 세그먼트 셀렉터 값 (index << 3 | RPL) */
#define __KERNEL32_CS (GDT_ENTRY_KERNEL32_CS * 8)      /* 0x08, Ring 0 */
#define __KERNEL_CS   (GDT_ENTRY_KERNEL_CS * 8)        /* 0x10, Ring 0 */
#define __KERNEL_DS   (GDT_ENTRY_KERNEL_DS * 8)        /* 0x18, Ring 0 */
#define __USER32_CS   (GDT_ENTRY_DEFAULT_USER32_CS * 8 + 3) /* 0x23, Ring 3 */
#define __USER_DS     (GDT_ENTRY_DEFAULT_USER_DS * 8 + 3)   /* 0x2B, Ring 3 */
#define __USER_CS     (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3)   /* 0x33, Ring 3 */

ARM64 아키텍처 (ARM64 / AArch64 Architecture)

ARM64(AArch64)는 모바일 기기부터 서버, 슈퍼컴퓨터까지 빠르게 확산되고 있는 아키텍처입니다. Apple Silicon(M1/M2/M3), AWS Graviton, Ampere Altra 등 고성능 ARM64 프로세서가 서버 시장에서도 중요한 위치를 차지하고 있습니다.

Exception Level (EL0 ~ EL3)

ARM64는 x86의 Ring 구조 대신 Exception Level(EL)이라는 4단계 특권 모델을 사용합니다. 각 EL은 명확한 역할을 가지며, 하위 EL에서 상위 EL로의 전환은 exception 발생 시에만 가능합니다.

• EL0 (User/Application) - 사용자 애플리케이션이 실행되는 레벨. 가장 낮은 특권.
• EL1 (OS Kernel) - 운영체제 커널이 실행되는 레벨. 리눅스 커널은 여기서 동작합니다.
• EL2 (Hypervisor) - 하이퍼바이저가 실행되는 레벨. KVM이 이 레벨을 사용합니다.
• EL3 (Secure Monitor) - ARM TrustZone의 Secure Monitor. 보안 세계와 일반 세계 전환을 관리합니다.

ARM64 부팅 과정 (Boot Process)

ARM64의 부팅 과정은 x86과 상당히 다릅니다. 대부분의 ARM64 시스템은 Device Tree를 사용하여 하드웨어 구성 정보를 커널에 전달합니다. 부팅 프로토콜은 커널 이미지의 시작점에 명시된 규약을 따릅니다.

MMIO와 Device Tree

ARM 시스템에서 하드웨어 레지스터에 접근하는 기본 방식은 MMIO(Memory-Mapped I/O)입니다. x86의 Port I/O(in/out 명령어)와 달리, ARM은 메모리 주소에 하드웨어 레지스터를 매핑하고 일반 메모리 접근 명령어(LDR/STR)로 제어합니다.

Device Tree(DT)는 하드웨어 구성을 기술하는 데이터 구조입니다. DTS(Device Tree Source) 파일로 작성하고, DTC(Device Tree Compiler)로 DTB(Device Tree Blob) 바이너리로 컴파일합니다. 커널은 부팅 시 DTB를 파싱하여 하드웨어 정보를 인식합니다.

/* 간단한 Device Tree 예시 (arch/arm64/boot/dts/example.dts) */

/dts-v1/;

/ {
    model = "Example ARM64 Board";
    compatible = "vendor,example-board";

    #address-cells = <2>;
    #size-cells = <2>;

    memory@80000000 {
        device_type = "memory";
        reg = <0x0 0x80000000 0x0 0x40000000>; /* 1GB @ 0x80000000 */
    };

    uart0: serial@9000000 {
        compatible = "arm,pl011", "arm,primecell";
        reg = <0x0 0x09000000 0x0 0x1000>; /* MMIO 영역 */
        interrupts = <0 1 4>;              /* GIC SPI #1, level */
        clock-names = "uartclk", "apb_pclk";
    };

    gic: interrupt-controller@8000000 {
        compatible = "arm,gic-v3";
        #interrupt-cells = <3>;
        interrupt-controller;
        reg = <0x0 0x08000000 0x0 0x10000>,  /* GICD */
              <0x0 0x080A0000 0x0 0xF60000>; /* GICR */
    };
};

RISC-V 아키텍처 (RISC-V Architecture)

RISC-V는 UC Berkeley에서 설계한 오픈 소스 ISA(Instruction Set Architecture)로, 라이센스 비용 없이 누구나 자유롭게 구현할 수 있습니다. 리눅스 커널은 RISC-V를 공식적으로 지원하며, SiFive, StarFive 등의 칩에서 이미 리눅스가 동작합니다.

특권 모드 (Privilege Modes)

RISC-V는 3단계 특권 모드를 정의합니다. 각 모드는 CSR(Control and Status Register) 접근 권한이 다릅니다.

• Machine Mode (M-mode) - 가장 높은 특권. 하드웨어에 직접 접근 가능. SBI 구현(OpenSBI)이 여기서 동작합니다.
• Supervisor Mode (S-mode) - 리눅스 커널이 실행되는 모드. 페이지 테이블과 인터럽트를 관리합니다.
• User Mode (U-mode) - 사용자 애플리케이션 모드. 가장 낮은 특권.

SBI (Supervisor Binary Interface)

SBI는 S-mode(커널)와 M-mode(펌웨어) 사이의 표준 인터페이스입니다. 리눅스 커널은 SBI 호출을 통해 타이머 설정, 프로세서 간 인터럽트(IPI) 전송, 콘솔 출력 등의 기계 수준 작업을 수행합니다. OpenSBI가 가장 널리 사용되는 SBI 구현체입니다.

/* arch/riscv/include/asm/sbi.h - SBI 호출 인터페이스 (간략화) */

/* SBI Extension IDs */
#define SBI_EXT_TIME           0x54494D45  /* "TIME" */
#define SBI_EXT_IPI            0x735049    /* "sPI"  */
#define SBI_EXT_RFENCE         0x52464E43  /* "RFNC" */
#define SBI_EXT_HSM            0x48534D    /* "HSM"  */

/* SBI 호출 수행 (ecall 명령어 사용) */
struct sbiret {
    long error;
    long value;
};

static inline struct sbiret sbi_ecall(int ext, int fid,
    unsigned long arg0, unsigned long arg1,
    unsigned long arg2, unsigned long arg3)
{
    struct sbiret ret;

    register unsigned long a0 asm("a0") = arg0;
    register unsigned long a1 asm("a1") = arg1;
    register unsigned long a6 asm("a6") = fid;
    register unsigned long a7 asm("a7") = ext;

    asm volatile("ecall"
        : "+r"(a0), "+r"(a1)
        : "r"(a6), "r"(a7)
        : "memory");

    ret.error = a0;
    ret.value = a1;
    return ret;
}

RISC-V 부팅 과정 (Boot Process)

RISC-V의 부팅 과정은 ARM64와 유사하게 여러 펌웨어 단계를 거칩니다. 현재 가장 일반적인 조합은 ZSBL → OpenSBI → U-Boot → Linux입니다.

특권 레벨 비교 (Privilege Level Comparison)

세 아키텍처의 특권 레벨 구조를 비교하면 설계 철학의 차이를 명확히 알 수 있습니다. 다음 다이어그램은 x86_64, ARM64, RISC-V의 특권 레벨을 나란히 비교합니다:

위 다이어그램에서 주목할 점은 리눅스 커널이 각 아키텍처에서 다른 특권 레벨에서 동작한다는 것입니다:

• x86_64: Ring 0에서 동작. Ring -1(VMX)은 하이퍼바이저 전용.
• ARM64: EL1에서 동작. EL2는 하이퍼바이저, EL3는 보안 모니터.
• RISC-V: S-mode에서 동작. M-mode는 SBI 펌웨어가 담당.

시스템 콜/예외 진입 경로 비교

사용자 공간에서 커널 공간으로 전환되는 공통 경로는 시스템 콜, 인터럽트, 예외입니다. 아키텍처별 진입 명령과 복귀 명령은 다르지만, 커널이 트랩 프레임을 저장하고 핸들러를 호출한 뒤 사용자 공간으로 복귀한다는 큰 흐름은 동일합니다.

• 시스템 콜 진입 명령: x86_64는 SYSCALL, ARM64는 SVC, RISC-V는 ecall을 사용합니다.
• 트랩 벡터: x86_64(IDT), ARM64(VBAR_EL1), RISC-V(stvec)가 첫 진입 지점을 결정합니다.
• 복귀 명령: x86_64(SYSRET/IRETQ), ARM64(ERET), RISC-V(sret)로 복귀합니다.

start_kernel() - 커널 초기화 진입점 (Kernel Init Entry)

모든 아키텍처에서 아키텍처별 초기화가 완료되면 start_kernel() 함수가 호출됩니다. 이 함수는 init/main.c에 정의되어 있으며, 커널의 공통 초기화를 수행하는 핵심 함수입니다.

/* init/main.c - start_kernel() 함수 (핵심 흐름 간략화) */

asmlinkage __visible void __init start_kernel(void)
{
    /* 아키텍처 의존적 초기화 (이전 단계에서 일부 수행) */
    setup_arch(&command_line);     /* 아키텍처별 설정 */

    /* 부팅 초기 메모리 할당자 (memblock) */
    setup_per_cpu_areas();          /* Per-CPU 영역 설정 */

    /* 핵심 서브시스템 초기화 */
    trap_init();                     /* 예외/인터럽트 벡터 설정 */
    mm_core_init();                  /* 메모리 관리 초기화 */
    sched_init();                    /* 스케줄러 초기화 */
    init_IRQ();                      /* 인터럽트 컨트롤러 설정 */
    time_init();                     /* 타이머 초기화 */
    console_init();                  /* 콘솔 초기화 */

    /* VFS 및 기타 서브시스템 */
    vfs_caches_init();              /* VFS 캐시 초기화 */
    signals_init();                  /* 시그널 초기화 */
    proc_root_init();               /* procfs 초기화 */

    /* 나머지 초기화 - kernel_init 스레드 생성 */
    arch_call_rest_init();          /* rest_init() → kernel_init() */

    /*
     * rest_init()에서:
     *  1. kernel_init 커널 스레드 생성 (PID 1의 전신)
     *  2. kthreadd 커널 스레드 생성 (PID 2)
     *  3. 현재 스레드는 idle 스레드(PID 0)가 됨
     *
     * kernel_init()에서:
     *  1. initcall 실행 (드라이버 초기화 등)
     *  2. /sbin/init 또는 /init 실행 → PID 1 프로세스
     */
}

커널 소스 트리 구조 (Kernel Source Tree Structure)

리눅스 커널 소스 코드는 기능별로 잘 정리된 디렉토리 구조를 가지고 있습니다. 커널 개발을 시작할 때 이 구조를 이해하는 것이 매우 중요합니다.

arch/ 디렉토리 상세 (Architecture Directory Detail)

arch/ 디렉토리 아래의 각 아키텍처 디렉토리는 비슷한 하위 구조를 가집니다. 이는 커널의 아키텍처 추상화 설계 원칙을 반영합니다:

• arch/<arch>/kernel/ - 프로세스 전환, 시스템 콜, SMP, 시그널 처리 등 핵심 아키텍처 코드
• arch/<arch>/mm/ - 페이지 테이블 관리, TLB 관리, 캐시 관리 등 메모리 관련 코드
• arch/<arch>/include/asm/ - 아키텍처별 헤더 파일 (인라인 어셈블리, 레지스터 정의 등)
• arch/<arch>/boot/ - 부트 코드, 부트 이미지 생성 스크립트
• arch/<arch>/configs/ - 기본 커널 설정 파일 (defconfig)
• arch/<arch>/Kconfig - 아키텍처별 Kconfig 옵션 정의

커널은 이러한 구조를 통해 아키텍처 독립적인 코드(kernel/, mm/ 등)와 아키텍처 의존적인 코드(arch/)를 깔끔하게 분리합니다. 새로운 아키텍처를 지원하려면 주로 arch/ 아래에 해당 아키텍처 디렉토리를 추가하면 됩니다.

빌드 설정 예시 (Build Configuration)

각 아키텍처의 기본 설정 파일(defconfig)로 빠르게 커널을 빌드할 수 있습니다:

# x86_64 기본 설정으로 커널 빌드
make x86_64_defconfig
make -j$(nproc)

# ARM64 크로스 컴파일
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make defconfig
make -j$(nproc) Image dtbs

# RISC-V 크로스 컴파일
export ARCH=riscv
export CROSS_COMPILE=riscv64-linux-gnu-
make defconfig
make -j$(nproc)

# QEMU로 빌드된 커널 테스트 (x86_64)
qemu-system-x86_64 \
    -kernel arch/x86/boot/bzImage \
    -initrd /path/to/initramfs.cpio.gz \
    -append "console=ttyS0" \
    -nographic

요약 (Summary)

이 문서에서는 리눅스 커널이 지원하는 주요 세 아키텍처의 핵심 개념을 살펴보았습니다. 각 아키텍처의 특성을 다음 표로 정리합니다:

아키텍처별 성능 최적화 (Architecture-Specific Performance Optimization)

각 아키텍처는 고유한 성능 특성과 최적화 포인트를 가지고 있습니다. 커널 개발자는 타겟 아키텍처의 특성을 이해하고 이에 맞는 최적화를 적용해야 합니다.

x86_64 최적화 포인트

/* x86_64 최적화 예제: 캐시 라인 정렬 */

struct hot_data {
    spinlock_t lock;
    u64 counter;
    void *ptr;
} __cacheline_aligned;  /* 64바이트 경계에 정렬 */

/* 분기 예측 힌트 */
if (unlikely(error_condition)) {
    handle_error();
    return -EINVAL;
}

/* likely는 정상 경로에 사용 */
if (likely(ptr != NULL)) {
    fast_path(ptr);
}

ARM64 최적화 포인트

/* ARM64 메모리 배리어 예제 */

/* 데이터 동기화 배리어 */
WRITE_ONCE(data->value, new_val);
smp_wmb();  /* Write Memory Barrier */
WRITE_ONCE(data->ready, 1);

/* 읽기 측 */
if (READ_ONCE(data->ready)) {
    smp_rmb();  /* Read Memory Barrier */
    val = READ_ONCE(data->value);
}

RISC-V 최적화 포인트

실전 디버깅 팁 (Debugging Tips)

아키텍처별 커널 디버깅은 각 플랫폼의 특성을 이해하고 적절한 도구를 사용해야 효과적입니다.

공통 디버깅 기법

/* 커널 디버그 출력 */
pr_debug("Variable x = %d\\n", x);         /* DEBUG 빌드에만 출력 */
pr_info("Info message\\n");                /* 정보성 메시지 */
pr_warn("Warning: %s\\n", msg);           /* 경고 */
pr_err("Error: %d\\n", errno);            /* 에러 */

/* WARN 및 BUG 매크로 */
WARN_ON(condition);                       /* 조건 만족 시 경고 + 백트레이스 */
WARN_ONCE(condition, "message");          /* 최초 1회만 경고 */
BUG_ON(critical_error);                   /* 치명적 에러 시 패닉 (사용 자제) */

/* 동적 디버그 */
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
pr_debug("Entry: func=%s\\n", __func__);

x86_64 특화 디버깅

ARM64 특화 디버깅

RISC-V 특화 디버깅

자주 묻는 질문 (FAQ)

Q1. 어떤 아키텍처를 선택해야 하나요?

A: 사용 목적에 따라 다릅니다:

• x86_64: 데스크탑, 서버, 클라우드 환경. 가장 성숙한 생태계와 도구 지원
• ARM64: 모바일, 임베디드, 저전력 서버 (AWS Graviton, Apple Silicon). 전력 효율 우수
• RISC-V: 연구, 교육, 새로운 HW 프로젝트. 오픈 ISA로 라이선스 비용 없음

Q2. 크로스 컴파일은 어떻게 하나요?

A: ARCH와 CROSS_COMPILE 변수를 설정합니다:

# ARM64 크로스 컴파일 (x86_64 호스트)
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc)

# RISC-V 크로스 컴파일
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig
make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j$(nproc)

자세한 내용은 빌드 시스템 (Build System) 문서를 참고하세요.

Q3. 32비트 커널도 여전히 사용되나요?

A: 예, 특정 임베디드 환경에서는 여전히 사용됩니다. ARM32 (AArch32), x86 (i386), MIPS32 등은 레거시 시스템이나 자원 제약 환경에서 사용되지만, 새로운 프로젝트는 대부분 64비트 아키텍처를 선택합니다. 주요 배포판들은 x86 32비트 지원을 점차 종료하고 있습니다.

Q4. ARM64의 big.LITTLE은 무엇인가요?

A: 고성능 코어(big)와 저전력 코어(LITTLE)를 조합한 이기종 멀티프로세싱(HMP) 아키텍처입니다. 리눅스 커널은 Energy Aware Scheduling (EAS)를 통해 워크로드에 따라 적절한 코어에 태스크를 할당합니다. 최신 ARM 시스템은 DynamIQ 기술을 사용하여 더 유연한 코어 조합을 지원합니다. 자세한 내용은 프로세스 스케줄러 (Process Scheduler) 문서를 참고하세요.

Q5. 페이지 테이블 레벨은 어떻게 결정되나요?

A: 가상 주소 공간 크기에 따라 결정됩니다:

• x86_64: 4-level (48-bit VA), 5-level (57-bit VA, CONFIG_X86_5LEVEL)
• ARM64: 3-level/4-level (VA/페이지 크기 설정에 따라 다름, 일반적으로 48-bit VA 구성 사용)
• RISC-V: Sv39 (3-level), Sv48 (4-level), Sv57 (5-level)

레벨이 많을수록 주소 공간은 넓어지지만 페이지 테이블 워킹 오버헤드가 증가합니다. 자세한 내용은 메모리 관리 (Memory Management) 및 메모리 관리 심화 (Advanced Memory Management) 문서를 참고하세요.

Q6. 아키텍처별 시스템 콜 차이는?

A: 시스템 콜 번호와 진입 메커니즘이 다릅니다:

• x86_64: syscall 명령어, 번호는 arch/x86/entry/syscalls/syscall_64.tbl
• ARM64: svc #0 명령어, 번호는 include/uapi/asm-generic/unistd.h
• RISC-V: ecall 명령어, 번호는 주로 asm-generic/unistd.h를 사용해 ARM64와 많은 항목을 공유

모든 아키텍처는 공통 시스템 콜 인터페이스를 제공하지만, 일부 아키텍처별 시스템 콜이 존재할 수 있습니다. 자세한 내용은 시스템 콜 (System Call) 문서를 참고하세요.

Q7. 가상화 오버헤드는 얼마나 되나요?

A: 하드웨어 가상화 지원 여부에 따라 크게 다릅니다:

• Hardware-assisted (VT-x, AMD-V, ARM VHE, RISC-V H-ext): 2~10% 오버헤드 (워크로드 의존)
• Paravirtualization (Xen PV): 하드웨어 지원 없을 때 사용, 오버헤드 더 높음
• I/O 가상화: 네트워크, 디스크 I/O에서 오버헤드 큼 → virtio, SR-IOV로 완화

현대 시스템에서는 하드웨어 가상화 지원이 표준이므로 오버헤드가 크지 않습니다. 자세한 내용은 가상화 (KVM) 문서를 참고하세요.

CPU 제조사 아키텍처 매뉴얼 (Architecture Software Developer's Manuals)

리눅스 커널 개발에서 각 CPU 제조사의 공식 아키텍처 매뉴얼은 가장 권위 있고 정확한 참조 문서입니다. 커널 코드의 아키텍처 의존 부분(arch/ 디렉토리)을 이해하거나 수정할 때 반드시 해당 매뉴얼을 참조해야 합니다.

Intel® 64 and IA-32 Architectures Software Developer's Manual (Intel SDM)

AMD64 Architecture Programmer's Manual (AMD APM)

ARM Architecture Reference Manual (ARM ARM)

RISC-V Specifications

매뉴얼 효과적 활용법

x86 CPU 실행 모드 심화 (Operating Modes)

x86 프로세서는 리셋 후 Real Mode에서 시작하여 여러 모드를 거쳐 Long Mode에 도달합니다. 리눅스 커널 부팅 과정은 이 모드 전환을 순차적으로 수행하며, 각 모드의 특성을 이해하는 것은 부트로더 코드와 커널 초기화 코드를 분석하는 데 필수적입니다.

모드 전환 흐름

Real Mode (리얼 모드)

; arch/x86/boot/header.S — 리눅스 부팅 초기 (Real Mode)
; BIOS가 이 코드를 0x7C00에 로드하여 실행

; A20 게이트 활성화 (20번째 주소 라인)
; A20이 비활성이면 1MB 이상 주소에 접근 불가
    in      al, 0x92        ; Fast A20 (System Port)
    or      al, 2
    out     0x92, al

; Protected Mode로 전환 준비
    lgdt    [gdt_ptr]        ; GDT 로드
    mov     eax, cr0
    or      eax, 1           ; PE (Protection Enable) 비트 설정
    mov     cr0, eax         ; → Protected Mode 진입!
    jmp     0x08:pm_entry   ; far jump로 CS 갱신 (GDT 셀렉터 0x08)

Protected Mode (보호 모드)

Protected Mode는 Intel 80286에서 도입되고 80386에서 완성된 32비트 실행 모드입니다. Real Mode의 한계(1MB 주소, 보호 없음)를 극복하여 4GB 주소 공간, 하드웨어 메모리 보호, 특권 레벨(Ring)을 제공합니다. 리눅스 32비트 커널(i386)은 이 모드에서 동작하며, 64비트 부팅에서도 Long Mode 진입 전 필수 경유 단계입니다.

Protected Mode 진입 상세

Real Mode에서 Protected Mode로 전환하려면 다음 단계를 정확한 순서로 수행해야 합니다. 하나라도 빠지면 Triple Fault로 시스템이 리셋됩니다.

; Protected Mode 진입 전체 흐름 (arch/x86/boot/pmjump.S 기반)

; ① 인터럽트 비활성화 — 모드 전환 중 인터럽트 금지
    cli

; ② A20 게이트 활성화 — 1MB 이상 메모리 접근 가능하게
    in      al, 0x92        ; Fast A20 (System Port)
    or      al, 2
    out     0x92, al

; ③ GDT 로드 — 세그먼트 디스크립터 테이블 설정
    lgdt    [gdt_ptr]        ; GDTR에 GDT base + limit 적재

; ④ CR0.PE = 1 — Protection Enable 비트 설정
    mov     eax, cr0
    or      eax, 1           ; PE 비트 (bit 0)
    mov     cr0, eax         ; → 이 순간 Protected Mode 진입!

; ⑤ far jump — CS를 GDT 코드 세그먼트 셀렉터로 갱신
;    이것이 없으면 명령어 프리페치 큐에 Real Mode 코드가 남아 있음
    jmp     0x08:pm_entry   ; GDT[1] = 코드 세그먼트 (셀렉터 0x08)

; ⑥ 데이터 세그먼트 레지스터 재적재
pm_entry:
    .code32
    mov     ax, 0x10        ; GDT[2] = 데이터 세그먼트 (셀렉터 0x10)
    mov     ds, ax
    mov     es, ax
    mov     fs, ax
    mov     gs, ax
    mov     ss, ax
    mov     esp, stack_top   ; 32비트 스택 설정

세그먼테이션 (Segmentation)

Protected Mode의 핵심 메커니즘은 세그먼테이션입니다. 모든 메모리 접근은 세그먼트 셀렉터를 통해 GDT/LDT의 디스크립터를 참조하여 선형 주소(Linear Address)로 변환됩니다.

GDT 엔트리 구조

/* GDT 엔트리 구조 (Intel SDM Vol.3 Section 3.4.5) */
struct gdt_entry {
    u16 limit_low;        /* 세그먼트 크기 [15:0]         (바이트 0-1) */
    u16 base_low;         /* 베이스 주소 [15:0]           (바이트 2-3) */
    u8  base_mid;          /* 베이스 주소 [23:16]          (바이트 4)   */
    u8  access;            /* P | DPL(2) | S | Type(4)     (바이트 5)   */
    u8  granularity;       /* G | D/B | L | AVL | Limit[19:16] (바이트 6) */
    u8  base_high;         /* 베이스 주소 [31:24]          (바이트 7)   */
} __attribute__((packed));

/* Access 바이트 비트 분해:
 * bit 7    : P   (Present) — 1이면 세그먼트 유효, 0이면 #NP 예외
 * bit 6-5  : DPL (Descriptor Privilege Level) — 00=Ring 0 ~ 11=Ring 3
 * bit 4    : S   (System) — 1=코드/데이터, 0=시스템(TSS, Call Gate 등)
 * bit 3-0  : Type — S=1일 때:
 *   코드: bit3=1, bit2=Conforming, bit1=Readable, bit0=Accessed
 *   데이터: bit3=0, bit2=Expand-down, bit1=Writable, bit0=Accessed
 */

/* Granularity 바이트 비트 분해:
 * bit 7    : G   (Granularity) — 0=바이트, 1=4KB 단위 (Limit × 4KB)
 * bit 6    : D/B (Default size) — 코드: 0=16bit, 1=32bit / 스택: 0=SP, 1=ESP
 * bit 5    : L   (Long mode) — 1=64bit 코드 (Long Mode 전용, D=0 필수)
 * bit 4    : AVL (Available) — OS가 자유롭게 사용
 * bit 3-0  : Limit [19:16] — Limit 상위 4비트
 */

Linux GDT 레이아웃

/* arch/x86/include/asm/segment.h — Linux GDT 레이아웃 */

/* 셀렉터 값 = (인덱스 << 3) | TI | RPL */
#define GDT_ENTRY_KERNEL32_CS   1   /* 0x08: Ring 0 32-bit 코드 */
#define GDT_ENTRY_KERNEL_CS     2   /* 0x10: Ring 0 64-bit 코드 */
#define GDT_ENTRY_KERNEL_DS     3   /* 0x18: Ring 0 데이터 */
#define GDT_ENTRY_DEFAULT_USER32_CS 4 /* 0x23: Ring 3 32-bit 코드 (RPL=3) */
#define GDT_ENTRY_DEFAULT_USER_DS   5 /* 0x2B: Ring 3 데이터 */
#define GDT_ENTRY_DEFAULT_USER_CS   6 /* 0x33: Ring 3 64-bit 코드 */
#define GDT_ENTRY_TSS           8   /* 0x40: TSS (16바이트, 2슬롯) */
#define GDT_ENTRY_LDT          10  /* 0x50: LDT (16바이트, 2슬롯) */
#define GDT_ENTRY_TLS_MIN      12  /* 0x60: TLS 엔트리 시작 */
#define GDT_ENTRY_PER_CPU      15  /* 0x78: per-CPU 데이터 */

/* Linux의 Flat 세그먼트 설정:
 * 코드/데이터 세그먼트 모두 Base=0, Limit=0xFFFFF, G=1
 * → 선형 주소 0x00000000 ~ 0xFFFFFFFF (4GB) 전체 커버
 * → 세그먼테이션을 사실상 무력화하고 페이징에 보호를 위임 */

Protected Mode 페이징 (2-Level)

페이징이 활성화되면(CR0.PG=1) 선형 주소는 페이지 디렉토리(PD)와 페이지 테이블(PT) 2단계를 거쳐 물리 주소로 변환됩니다.

Ring 전환 메커니즘

Protected Mode의 Ring 전환(유저 → 커널, 커널 → 유저)은 인터럽트/예외, SYSENTER/SYSEXIT, Call Gate를 통해 수행됩니다. Ring 전환 시 CPU는 자동으로 TSS에서 새 Ring의 스택(SS:ESP)을 로드합니다.

/* Ring 전환 시 CPU 자동 동작:
 *
 * Ring 3 → Ring 0 (인터럽트/예외):
 *   1. TSS에서 Ring 0의 SS0:ESP0 로드
 *   2. 이전 SS:ESP를 새 스택에 push
 *   3. EFLAGS push
 *   4. CS:EIP push (복귀 주소)
 *   5. 에러 코드 push (해당 시)
 *   6. IDT에서 새 CS:EIP 로드 → 핸들러 진입
 *
 * Ring 0 → Ring 3 (IRET):
 *   1. 스택에서 EIP, CS, EFLAGS pop
 *   2. CS의 RPL이 현재 CPL보다 높으면 (유저 복귀)
 *   3. 스택에서 ESP, SS 추가 pop
 *   4. Ring 3 코드 실행 재개
 */

/* SYSENTER/SYSEXIT (Pentium II+, 32비트):
 * SYSENTER: Ring 3 → Ring 0 (MSR에서 CS/EIP/ESP 로드)
 *   IA32_SYSENTER_CS  (0x174) → 커널 CS
 *   IA32_SYSENTER_ESP (0x175) → 커널 ESP
 *   IA32_SYSENTER_EIP (0x176) → 커널 진입점
 * SYSEXIT:  Ring 0 → Ring 3 (ECX=유저 ESP, EDX=유저 EIP)
 */
wrmsrl(MSR_IA32_SYSENTER_CS, __KERNEL_CS);
wrmsrl(MSR_IA32_SYSENTER_ESP, tss->x86_tss.sp0);
wrmsrl(MSR_IA32_SYSENTER_EIP,
    (unsigned long)entry_SYSENTER_32);

PAE (Physical Address Extension)

Long Mode (IA-32e Mode / 64-bit Mode)

Long Mode는 AMD64(Intel에서는 IA-32e Mode)로 명명된 64비트 실행 모드입니다. 64비트 범용 레지스터, 최대 256TB(48비트) 또는 128PB(57비트) 가상 주소 공간, 4-/5-level 페이징, SYSCALL/SYSRET 고속 시스템 콜, NX(No-Execute) 비트 등을 제공합니다. 현대 리눅스 커널(x86_64)은 이 모드에서 동작합니다.

Long Mode 진입 상세

Protected Mode에서 Long Mode로의 전환은 정확한 순서가 필수입니다. 순서가 틀리면 #GP(General Protection Fault) 또는 Triple Fault가 발생합니다.

; arch/x86/boot/compressed/head_64.S — Long Mode 전환 (간략화)
    .code32
startup_32:
; ① 페이징이 켜져 있으면 끔 (UEFI에서 올 때)
    movl    %cr0, %eax
    andl    $~X86_CR0_PG, %eax
    movl    %eax, %cr0

; ② PAE 활성화
    movl    %cr4, %eax
    orl     $X86_CR4_PAE, %eax
    movl    %eax, %cr4

; ③ Identity-mapped PML4 페이지 테이블 구성
;    가상주소 = 물리주소 (전환 직후 코드가 같은 주소에서 실행되도록)
    leal    pgtable(%ebx), %edi
    xorl    %eax, %eax
    movl    $(BOOT_INIT_PGT_SIZE/4), %ecx
    rep     stosl                  ; 0으로 초기화

    ; PML4[0] → PDPT
    leal    pgtable + 0x1007(%ebx), %eax
    movl    %eax, pgtable + 0(%ebx)

    ; PDPT[0] → PD (2MB 대형 페이지 사용)
    leal    pgtable + 0x2007(%ebx), %eax
    movl    %eax, pgtable + 0x1000(%ebx)

; ④ CR3에 PML4 물리 주소 적재
    leal    pgtable(%ebx), %eax
    movl    %eax, %cr3

; ⑤ EFER.LME = 1 (Long Mode Enable)
    movl    $MSR_EFER, %ecx
    rdmsr
    btsl    $_EFER_LME, %eax       ; bit 8
    wrmsr

; ⑥ CR0.PG = 1 → Long Mode 활성화!
;    이 순간 EFER.LMA=1이 자동으로 설정됨
    movl    %cr0, %eax
    orl     $X86_CR0_PG, %eax
    movl    %eax, %cr0

; ⑦ far JMP → 64-bit 코드 세그먼트 (CS.L=1)
;    이 JMP는 CPU의 명령어 디코더를 64-bit 모드로 전환
    ljmpl   $__KERNEL_CS, $startup_64

; === 여기서부터 64-bit 코드 ===
    .code64
startup_64:
    ; 64-bit 레지스터 사용 가능
    xorq    %rax, %rax     ; 64-bit zero
    movq    %rax, %ds      ; Long Mode에서 DS/ES/SS base=0 강제
    movq    %rax, %es
    movq    %rax, %ss
    movq    %rax, %fs
    movq    %rax, %gs

4-Level 페이징 (PML4)

Long Mode에서 페이징은 필수이며, 최소 4단계 페이지 테이블을 사용합니다. 각 테이블은 512개 엔트리(각 8바이트)로 구성되어 4KB를 차지합니다.

Protected Mode vs Long Mode 페이징 비교

레지스터 확장

Long Mode에서는 기존 8개 범용 레지스터가 64비트로 확장되고, R8~R15 8개 레지스터가 추가됩니다. REX 프리픽스가 이 확장 레지스터 접근을 가능하게 합니다.

Long Mode에서의 세그먼테이션 변화

Long Mode는 세그먼테이션을 대부분 비활성화합니다. Protected Mode에서 핵심이었던 세그먼트 Base/Limit이 무시됩니다.

/* Long Mode에서 FS/GS Base 설정 (MSR 사용) */
/* 커널 per-CPU 데이터 접근: GS Base */
wrmsrl(MSR_GS_BASE, per_cpu_offset(cpu));
/* 이후 %gs:offset 으로 per-CPU 변수 접근 */
/* 예: movq %gs:current_task, %rax → 현재 task_struct */

/* 유저 TLS(Thread-Local Storage): FS Base */
wrmsrl(MSR_FS_BASE, thread->fsbase);
/* glibc의 __thread 변수는 FS Base 기준으로 접근 */

/* SWAPGS: 시스템 콜 진입 시 GS 교체 */
/* SYSCALL → GS = 유저 값 → SWAPGS → GS = 커널 per-CPU */
/* SYSRET 전 → SWAPGS → GS = 유저 값 복원 */

Long Mode 서브모드

Protected Mode vs Long Mode 종합 비교

CPU 모드 전환 주의사항

제어 레지스터(CR) 요약

Descriptor Table 레지스터 구조

GDTR/IDTR 레지스터는 GDT와 IDT의 위치를 CPU에 알려주는 특수 레지스터입니다. LGDT/LIDT 명령어로 메모리의 의사 디스크립터(Pseudo-Descriptor)를 읽어 적재하며, Protected Mode에서는 48비트(6바이트), Long Mode에서는 80비트(10바이트) 구조를 사용합니다.

리눅스 커널은 arch/x86/include/asm/desc.h에서 GDT/IDT 적재를 위한 인라인 함수를 제공합니다:

/* arch/x86/include/asm/desc.h */

/* LGDT/LIDT 명령어가 받는 6/10바이트 메모리 구조 */
struct desc_ptr {
    u16 size;       /* 테이블 바이트 크기 - 1 (Limit) */
    u64 address;    /* 테이블 선형 주소 (Base) */
} __attribute__((packed));

static __always_inline void native_load_gdt(const struct desc_ptr *dtr)
{
    asm volatile("lgdt %0" : : "m"(*dtr));
}

static __always_inline void native_load_idt(const struct desc_ptr *dtr)
{
    asm volatile("lidt %0" : : "m"(*dtr));
}

/* 사용 예시: 부팅 시 GDT 설정 */
/* arch/x86/kernel/head64.c */
struct desc_ptr gdt_descr = {
    .size    = GDT_SIZE - 1,
    .address = (unsigned long)get_cpu_gdt_rw(0),
};
load_gdt(&gdt_descr);

세그먼트 디스크립터 비트 필드 상세

GDT/LDT의 각 엔트리는 8바이트(64비트) 세그먼트 디스크립터입니다. 비트 배치가 연속적이지 않아 소프트웨어에서 직접 조립할 때 주의가 필요합니다. 인텔 SDM Vol.3 Section 3.4.5의 "Segment Descriptor"를 기준으로 설명합니다.

/* GDT_ENTRY() 매크로 — arch/x86/include/asm/desc_defs.h */
/* base: 32비트 세그먼트 베이스, limit: 20비트 크기, flags: 접근·세분성 바이트 */
#define GDT_ENTRY(flags, base, limit)                                  \
    ((((base)  & _AC(0xff000000,ULL)) << (56-24)) | \
     (((flags) & _AC(0x0000f0ff,ULL)) << 40)      | \
     (((limit) & _AC(0x000f0000,ULL)) << (48-16)) | \
     (((base)  & _AC(0x00ffffff,ULL)) << 16)       | \
     (((limit) & _AC(0x0000ffff,ULL))))

/* 사용 예: Ring 0 64-bit 코드 세그먼트 (CS=0x10, Long Mode) */
/* flags=0xa09b: G=1, L=1, P=1, DPL=0, S=1, Type=0xb (코드/실행/읽기) */
GDT_ENTRY(0xa09b, 0, 0xfffff)

시스템 세그먼트 디스크립터 (S=0)

GDT 디스크립터의 S(Descriptor Type) 비트가 0이면 시스템 디스크립터입니다. 코드/데이터 세그먼트(S=1)와 달리 TSS, LDT, 각종 Gate를 기술하며, Long Mode에서 TSS와 LDT 디스크립터는 128비트(16바이트)로 확장되어 GDT에서 연속된 두 슬롯을 차지합니다.

리눅스 커널은 arch/x86/include/asm/desc_defs.h에서 시스템 디스크립터를 위한 구조체를 정의합니다:

/* arch/x86/include/asm/desc_defs.h */

/* Long Mode TSS/LDT 디스크립터: GDT에서 연속된 2슬롯(16바이트) 차지 */
struct ldttss_desc {
    u16 limit0;         /* Limit[15:0] */
    u16 base0;          /* Base[15:0] */
    unsigned base1:8,   /* Base[23:16] */
             type:5,    /* Type (S=0 포함된 5비트) */
             dpl:2,     /* 디스크립터 권한 레벨 */
             p:1;       /* Present 비트 */
    unsigned limit1:4,  /* Limit[19:16] */
             zero0:3,   /* Reserved = 0 */
             g:1,       /* Granularity (1=4KB 단위) */
             base2:8;   /* Base[31:24] */
    u32 base3;          /* Base[63:32] — 두 번째 QWord */
    u32 zero1;          /* Reserved = 0 */
} __attribute__((packed));

/* TSS 디스크립터 설정 예시 (arch/x86/kernel/cpu/common.c) */
set_tssldt_descriptor(&get_cpu_entry_area(cpu)->tss_desc,
                      (unsigned long)&get_cpu_entry_area(cpu)->tss.x86_tss,
                      DESC_TSS,
                      __KERNEL_TSS_LIMIT);

IDT 게이트 디스크립터 구조 상세

64비트 Long Mode의 IDT 엔트리는 16바이트(128비트)로, Protected Mode의 8바이트에서 확장되었습니다. 핸들러 오프셋이 64비트로 늘어났으며, IST(Interrupt Stack Table) 필드가 추가되어 중첩 예외 상황에서도 안전한 전용 스택을 사용할 수 있습니다.

/* struct gate_struct — arch/x86/include/asm/desc_defs.h */
struct gate_struct {
    u16    offset_low;    /* 핸들러 주소 [15:0] */
    u16    segment;       /* 코드 세그먼트 셀렉터 (예: __KERNEL_CS = 0x10) */
    struct idt_bits bits; /* IST[2:0] | 0[4:0] | Type[3:0] | 0 | DPL[1:0] | P */
    u16    offset_middle; /* 핸들러 주소 [31:16] */
    u32    offset_high;   /* 핸들러 주소 [63:32] */
    u32    reserved;      /* 반드시 0 */
} __attribute__((packed));

/* 인터럽트 게이트 설정 예 (arch/x86/kernel/idt.c) */
set_intr_gate(X86_TRAP_DE, asm_exc_divide_error); /* #DE: DPL=0, IF 클리어 */
set_system_intr_gate(X86_TRAP_BP, asm_exc_int3);  /* #BP: DPL=3, 사용자→int3 허용 */

CPL/DPL/RPL 특권 레벨 메커니즘

x86은 4개의 특권 레벨(Ring 0~3)을 지원하며, 세그먼트 접근 시 CPU가 자동으로 세 가지 레벨을 비교합니다. 리눅스는 Ring 0(커널)과 Ring 3(사용자)만 사용하며, Ring 1/2는 활용하지 않습니다.

; Ring 3 → Ring 0 전환 시 CPU가 자동으로 수행하는 동작
; (예외/인터럽트 발생 시, CALL 게이트 사용 시)
;
; 1. CPL 변경 감지: 새 DPL < 현재 CPL → 스택 전환 수행
; 2. TSS.RSP0에서 Ring 0 커널 스택 포인터 로드
; 3. 현재 컨텍스트를 새 스택에 자동 푸시 (5개 항목):
;    [+40]: SS   (원래 Ring 3 스택 세그먼트)
;    [+32]: RSP  (원래 Ring 3 스택 포인터)
;    [+24]: RFLAGS
;    [+16]: CS   (원래 Ring 3 코드 세그먼트)
;    [ +8]: RIP  (원래 복귀 주소)
;    [  0]: Error Code (예외인 경우에만 푸시)
;
; 복귀: IRET → 저장된 SS/RSP/RFLAGS/CS/RIP 복원
;       CPL이 높아지면 자동으로 Ring 3 스택으로 복귀

SYSCALL/SYSRET 메커니즘 상세

현대 리눅스 커널은 시스템 콜에 INT 0x80/IRET 대신 SYSCALL/SYSRET 명령어를 사용합니다. 이 명령어들은 세그먼트 디스크립터 검사를 생략하고 MSR에서 직접 CS/SS 셀렉터와 진입점 주소를 읽어 Ring 3 ↔ Ring 0 전환을 수행합니다.

리눅스 커널의 syscall_init()에서 부팅 시 MSR을 설정합니다:

/* arch/x86/kernel/cpu/common.c */
void syscall_init(void)
{
    /*
     * STAR: [63:48] = SYSRET용 CS 기준 셀렉터
     *       [47:32] = SYSCALL용 CS 셀렉터 (__KERNEL_CS)
     * SYSRET 시 CPU는 STAR[63:48]을 CS로, +8을 SS로 사용
     */
    wrmsrl(MSR_STAR, ((u64)__USER32_CS) << 48 |
                     ((u64)__KERNEL_CS) << 32);

    /* LSTAR: 64비트 SYSCALL 진입점 */
    wrmsrl(MSR_LSTAR, (u64)entry_SYSCALL_64);

#ifdef CONFIG_IA32_EMULATION
    /* CSTAR: 32비트 Compatibility Mode SYSCALL 진입점 */
    wrmsrl(MSR_CSTAR, (u64)entry_SYSCALL_compat);
#endif

    /*
     * SFMASK: SYSCALL 진입 시 RFLAGS에서 클리어할 비트
     * TF(트레이스), DF(방향), IF(인터럽트 금지), NT(중첩 태스크),
     * AC(정렬 확인), IOPL 등을 클리어하여 보안 강화
     */
    wrmsrl(MSR_SYSCALL_MASK,
           X86_EFLAGS_TF | X86_EFLAGS_DF | X86_EFLAGS_IF |
           X86_EFLAGS_IOPL | X86_EFLAGS_AC | X86_EFLAGS_NT);
}

TSS (Task State Segment) 구조

Long Mode의 TSS는 하드웨어 멀티태스킹 지원 대신 스택 포인터 저장소로 사용됩니다. CPU는 예외/인터럽트 발생 시 TSS에서 스택 포인터를 가져옵니다. 리눅스는 CPU마다 하나의 TSS를 유지하며, 태스크 전환(context switch)마다 RSP0를 갱신합니다.

/* struct x86_hw_tss — arch/x86/include/asm/processor.h (단순화) */
struct x86_hw_tss {
    u32  reserved1;
    u64  sp0;          /* RSP0: Ring 0 진입 시 커널 스택 최상단 */
    u64  sp1;          /* RSP1: Ring 1 (리눅스 미사용, 항상 0) */
    u64  sp2;          /* RSP2: Ring 2 (리눅스 미사용, 항상 0) */
    u64  reserved2;
    u64  ist[7];       /* IST1~7: NMI, #DF, #MC 등 전용 스택 포인터 */
    u32  reserved3;
    u32  reserved4;
    u16  reserved5;
    u16  io_bitmap_base; /* IOPB 오프셋 (0x68 = IOPB 없음) */
} __attribute__((packed));

/* RSP0 갱신 — arch/x86/kernel/process_64.c */
/* __switch_to() 호출 시마다 새 태스크의 커널 스택 최상단을 RSP0에 기록 */
/* this_cpu_write(cpu_tss_rw.x86_tss.sp0, task_top_of_stack(next_p)); */

Long Mode 특화 기능 상세

Long Mode는 단순히 64비트 레지스터와 넓은 주소 공간만 제공하는 것이 아닙니다. Canonical 주소 규칙, REX 프리픽스, FS/GS Base MSR, RIP-relative 주소 지정 등 시스템 소프트웨어가 반드시 이해해야 할 고유 메커니즘을 포함합니다.

; arch/x86/entry/entry_64.S — 시스템 콜 진입 (Ring 3 → Ring 0)
; SYSCALL 실행 후: GS.base = 사용자 GS 값 (그대로 유지됨)
; per-CPU 데이터 접근을 위해 SWAPGS로 커널 GS.base를 복원해야 함
SYM_CODE_START(entry_SYSCALL_64):
    swapgs                    ; GS.base ↔ KernelGS.base 교체
                              ; 이후 %gs:offset = current_task 등 per-CPU 변수 접근 가능
    ; ... 커널 스택 설정, 레지스터 저장 ...

; Ring 0 → Ring 3 복귀
SYM_CODE_START(syscall_return_via_sysret):
    swapgs                    ; 사용자 GS.base 복원 (KernelGS.base에 커널 값 보관)
    sysretq                   ; Ring 3 복귀 (RCX→RIP, R11→RFLAGS)

; RIP-relative 주소 지정 — PIE/KASLR 호환
; Long Mode에서 [rip + disp32] 형식으로 현재 명령어 기준 ±2GB 내 접근
; 어셈블러가 자동으로 다음 명령어 주소와의 차이를 계산
    lea     rax, [rip + my_symbol]    ; RIP-relative LEA: 심볼 주소를 위치 독립적으로 로드
    mov     rbx, [rip + global_var]   ; 전역 변수 접근: 재배치 없이 동작
; 컴파일러: -fPIC 또는 -fPIE 플래그 → 자동으로 RIP-relative 코드 생성
; 커널 KASLR: 임의 주소에 로드되어도 내부 참조는 상대 오프셋으로 유효

아키텍처 분석 플레이북

아키텍처 문서를 읽을 때는 개념 암기보다 "실제 커널 코드에서 어디서 소비되는지"를 함께 확인해야 이해가 빠르게 고정됩니다. 아래 절차는 x86_64, ARM64, RISC-V를 공통 틀로 비교할 때 유용합니다.

# 아키텍처별 엔트리 코드 빠른 점검
git grep -n "SYSCALL\|el0_svc\|do_trap" -- arch/x86 arch/arm64 arch/riscv

# 페이지 테이블 핵심 경로 확인
git grep -n "pgd\|pud\|pmd\|pte" -- arch/*/include/asm arch/*/mm

# 부팅 초기 코드 진입점 확인
git grep -n "start_kernel\|head_.*\.S" -- arch/* init/main.c

관련 문서

커널 아키텍처와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

• 홈 — 리눅스 커널 소개
• 부팅 과정 — 커널 부팅 과정
• 프로세스 관리 — 프로세스와 태스크 구조체
• 메모리 관리 (기초) — 메모리 아키텍처
• 프로세스 스케줄러 — 스케줄러 아키텍처
• CPU 토폴로지 — CPU 아키텍처