커널 아키텍처 (Kernel Architecture)

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

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

왜 커널 아키텍처를 알아야 할까요? 같은 C 코드라도 x86_64에서 문제없이 동작하던 코드가 ARM64에서 데이터 경쟁 버그로 이어지거나, RISC-V에서는 존재하지 않는 확장 명령어에 의존해 빌드 오류가 발생할 수 있습니다. 커널 드라이버·서브시스템 코드를 이식하거나, 부팅 실패를 디버깅하거나, 특권 레벨 경계를 넘는 보안 취약점을 분석할 때 아키텍처 지식이 없으면 근본 원인에 도달하기 어렵습니다. 이 문서는 세 아키텍처 각각의 특권 모델·메모리 주소 공간·부팅 경로·레지스터 체계를 커널 코드와 연결하여 설명합니다.

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

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

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

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

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

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

x86_64 아키텍처 (x86_64 Architecture)

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

부팅 과정

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

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

/* 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 기준 주소 공간 레이아웃을 보여줍니다:

아키텍처별 주소 변환(Address Translation) 경로 비교

가상 주소(Virtual Address)를 물리 주소(Physical Address)로 변환하는 핵심 경로는 세 아키텍처 모두 유사하지만, 제어 레지스터(Register)와 페이지 테이블 포맷이 다릅니다. 아래 다이어그램은 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 엔트리, 최종 물리 페이지(Page) 매핑(Mapping)

링 구조 (Protection Rings)

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

MSR (Model-Specific Register)

MSR은 프로세서 모델별로 정의되는 특수 레지스터로, 성능 카운터, 전원 관리, 터보 부스트, virtualization 기능 등을 제어합니다. 리눅스 커널은rdmsr/wrmsr 명령어로 MSR에 접근합니다.

/* arch/x86/include/asm/msr.h - MSR 접근 매크로 */

/* MSR 읽기 */
static inline u64 rdmsrl(unsigned int msr)
{
    u64 val;
    asm volatile("rdmsr" : "=A"(val) : "c"(msr));
    return val;
}

/* MSR 쓰기 */
static inline void wrmsrl(unsigned int msr, u64 val)
{
    asm volatile("wrmsr" : : "c"(msr), "A"(val));
}

/* 시스템 콜 진입 MSR 설정 예시 */
wrmsrl(MSR_LSTAR, (unsigned long)entry_SYSCALL_64);
wrmsrl(MSR_FMASK, 0);
wrmsrl(MSR_STAR, ((u64)__KERNEL_CS << 32) | (__USER_CS << 16));

x86_64 시스템 콜 Internals

x86_64 시스템 콜은SYSCALL 명령어로 진입하며, MSR에 설정된 핸들러 주소로 점프합니다. 복귀는SYSRET 명령어로 수행됩니다.

/* arch/x86/entry/entry_64.S - syscall 진입 흐름 (핵심 부분) */

/* 사용자 공간에서 SYSCALL */
    syscall                    /* RAX=syscall 번호, RDI, RDI, RDX, RSI, R8, R9 = 인자 */
                                /* RIP → MSR_LSTAR에 저장된 주소 */

entry_SYSCALL_64:
    /* 레지스터 저장 (pt_regs 구조체) */
    push   %rax           /* RAX 저장 (syscall 번호) */
    cld
    push   %r15
    push   %r14
    push   %r13
    push   %r12
    push   %r11           /* RFLAGS 저장 */
    push   %r10
    push   %r9
    push   %r8
    push   %rcx           /* RIP 저장 (복귀 주소) */
    push   %r11          /* RFLAGS 재저장 */
    push   %rdx
    push   %rsi
    push   %rdi
    push   %rbp
    push   %rax           /* syscall 번호 */

    /* GS 기반 per-CPU 접근 시작 */
    SWAPGS                /* GS → 커널 GS로 교체 */

    /* 시스템 콜 테이블에서 핸들러 호출 */
    mov    %rsp, %gs:thread_struct.sp0  /* 커널 스택 설정 */
    mov    %rsp, %rsp
    test   $3, %rsp          /* Ring 3에서 호출? */
    jz     1f
    swapgs
1:
    and    $-16, %rsp
    mov    %rsp, %gs:cpu_tss.x86_tss.sp1
    leaq   -RED_ZONE_SIZE(%rsp), %rsp
    push   %rsp
    push   %gs:cpu_tss.x86_tss.sp0

    /* syscall 테이블 호출 */
    mov    %rax, %rsp
    sub    $SIZEOF(pt_regs), %rsp
    mov    %rax, %rsp        /* pt_regs 빌드 */
    mov    %rax, %rsp, %rdi
    call   do_syscall_64
    /* 복귀 */
    ret

syscall_return:
    SWAPGS
    sysretq              /*Ring 3 복귀, RIP=RCX, RFLAGS=RDX */

x86_64 인터럽트 처리

x86_64의 인터럽트 처리는 IDT(Interrupt Descriptor Table)과 LAPIC(Local APIC)가 담당합니다. 예외, IRQ, NMI 모두 IDT 게이트를 통해 처리됩니다.

/* arch/x86/include/asm/desc.h - IDT 게이트 구조 */

struct gate_struct {
    u16 offset_low;         /* offset [15:0] */
    u16 selector;           /* 코드 세그먼트 셀렉터 */
    u8  ist;                /* Interrupt Stack Table */
    u8  type_attr;         /* Type (0x6=Interrupt, 0x7=Trap) | DPL | P */
    u16 offset_mid;       /* offset [31:16] */
    u32 offset_high;       /* offset [63:32] */
    u32 reserved;       /* 보존 */
} __attribute__((packed));

/* IRQ 벡터 할당 */
#define FIRST_EXTERNAL_VECTOR    0x20  /* IRQ0 */
#define FIRST_SYSTEM_VECTOR  0xE0  /* Local APIC */
#define GLOBAL_INTR_VECTORS    224    /* IRQ0~15 + IOAPIC */

VMX (Virtualization) Internals

VMX는 Intel의 하드웨어 가상화 확장입니다. VMX root mode(Ring -1)와 VMX non-root mode(게스트)를 지원합니다.

/* arch/x86/kvm/vmx.h - VMX 주요 MSR */

#define MSR_IA32_VMX_BASIC             0x480
#define MSR_IA32_VMX_PINCTRL         0x481
#define MSR_IA32_VMX_PROCCTRL        0x482
#define MSR_IA32_VMX_EXITCTRL       0x483
#define MSR_IA32_VMX_ENTRYCTRL        0x484

/* VMCS 필드 */
#define VMCS_GUEST_RIP               0x00001602
#define VMCS_GUEST_RSP               0x00001603
#define VMCS_GUEST_CR3               0x00001602
#define VMCS_HOST_CR3               0x00001902
#define VMCS_HOST_RSP               0x00001903
#define VMCS_HOST_RIP               0x00001904

/* VMX 실행 상태 (VMCS field: VMCS_GUEST_ACTIVITY_STATE) */
#define VMX_GUEST_STATE_ACTIVE       0
#define VMX_GUEST_STATE_HLT          1
#define VMX_GUEST_STATE_SHUTDOWN      2
#define VMX_GUEST_STATE_WAIT_SIPI     3

/* 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/M4), AWS Graviton4, Ampere Altra/AmpereOne 등 고성능 ARM64 프로세서가 서버 시장에서도 중요한 위치를 차지하고 있습니다.

ARM64는 x86_64와 비교해 세 가지 설계 철학의 차이를 먼저 이해해야 합니다. 첫째, RISC 기반으로 명령어 수가 적고 길이가 고정(4바이트)되어 있어 파이프라인 설계가 단순합니다. 둘째, x86의 Ring 0~3 대신 Exception Level(EL0~EL3)이라는 4단계 모델을 사용하며, TrustZone(EL3)으로 보안 세계와 일반 세계를 하드웨어 수준에서 격리합니다. 셋째, 메모리 순서가 약한 모델(Weak Ordering)이어서 명시적 배리어 없이는 멀티코어 환경에서 쓰기 순서가 보장되지 않습니다. x86에서 포팅한 코드에 배리어가 빠져 있어도 x86 하드웨어의 강한 메모리 순서 덕분에 동작하던 코드가, ARM64에서는 산발적인 데이터 경쟁 버그로 나타나는 것이 가장 흔한 포팅 실수입니다.

Exception Level (EL0 ~ EL3)

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

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

ARM64 시스템 레지스터

ARM64는 x86의 MSR과 유사하게MSR/MRS 명령어로 접근하는 시스템 레지스터를 사용합니다. 시스템 레지스터는SCTLR_ELx, TTBR0_EL1, TCR_EL1 등 EL별로 나뉩니다.

/* ARM64 시스템 레지스터 접근 예시 */

/* MMU 활성화 (SCTLR_EL1.M = 1) */
    mrs    x0, sctlr_el1
    orr    x0, x0, #1        /* M 비트 */
    msr    sctlr_el1, x0

/* 페이지 테이블 베이스 설정 (TTBR0_EL1) */
    msr    ttbr0_el1, x0

/* 인터럽트 허용 (DAIF 클리어) */
    msr    daif, #0

/* 현재 EL 확인 */
    mrs    x0, currentel
    lsr    x0, x0, #2        /* 0=EL0, 1=EL1, 2=EL2, 3=EL3 */

GIC (Generic Interrupt Controller)

ARM64 시스템의 인터럽트 컨트롤러는 GIC(Generic Interrupt Controller)입니다. GICv2, GICv3, GICv4 버전이 있으며, 버전별로 프로그래밍 인터페이스가 다릅니다.

/* drivers/irqchip/irq-gic-v3.c - GICv3 초기화 핵심 */

/* Redistributor베이스 주소 */
#define GICR_CTLR        0x0
#define GICR_TYPER        0x08
#define GICR_PIDR2       0xFE8

/* Interrupt ID Ranges */
#define GIC_SPI_OFFSET     32    /* SPI: 32~1019 */
#define GIC_PPI_OFFSET      16    /* PPI: 16~31 */
#define GIC_SGI_OFFSET      0      /* SGI: 0~15 */

/* GICD_IROUTERn - Interrupt Routing Register */
/* Each SPI routing to target redistributors */

static int gic_set_affinity(struct irq_data *d, const cpumask *mask, bool force)
{
    void __iomem *reg = gic_dist_base(d) + GIC_DIST_TARGET + irq(d);
    u32 target = cpu_logical_map(cpumask_first(mask));
    writel_relaxed(target, reg);
    return IRQ_SET_MASK_OK;
}

ARM64 KVM 가상화

ARM64에서 KVM은 하이퍼바이저로 동작하며, EL2에서 실행됩니다.CONFIG_KVM와CONFIG_ARM64_VHE 옵션이 있습니다.

• VHE (Virtualization Host Extensions): 커널이 EL2에서 직접 실행되어 오버헤드 없음
• 비VHE: 분리된 커널/VMM 필요 (전통적 구성)

/* arch/arm64/kvm/arm.c - KVM 초기화 */

static int kvm_init(void)
{
    int ret;

    /* Hyp 시스템 레지스터 초기화 */
    kvm_linux_set_id_aa64pfr0(0);
    kvm_linux_set_id_aa64pfr1(0);
    kvm_linux_set_id_aa64zfr0(0);

    /* 2단계 페이지 테이블 활성화 */
    if (has_vhe()) {
        kvm_init_el2_stuff();
    }

    return 0;
}

/* VM 생성 시 2단계 페이지 테이블 설정 */
static int kvm_init_stage2(struct kvm *kvm)
{
    phys_addr_t pgd = __get_free_pages(GFP_KERNEL, VTCR_SIZE_BITS);

    /* Hyp 레지스터에 2단계 테이블 베이스 설정 */
    write_sysreg(pgd, vtcr_el2);
    write_sysreg(pgd, vttbr_el2);
    return 0;
}

ARM64 보안 확장 (PAC, BTI, MTE, GCS)

ARM64는 다양한 하드웨어 기반 보안 확장을 제공합니다.

/* PAC (Pointer Authentication) 예시 */

/* PACIA 키 생성 (A 키 사용) */
    pacia  x0, x1, x2    /* x0 = x0 | PAC(x1, x2) */

/* PACIB (B 키 사용) */
    pacib  x0, x1, x2

/* AUTIA 복호화 검증, 실패 시 BRK */
    autia  x0, x1, x2

/* BTI (Branch Target Identification) */
    /* BTI 테스트 */
    bti    "c"           /* Call-friendly target */
    bti    "j"           /* Jump-friendly target */
    bti    "i"           /* Indirect branch target */
    bti    "c,j"         /* Both */

/* MTE (Memory Tagging) */
    irg    x0, x1           /* Allocate random tag in x0, base in x1 */
    stg    x0, [x1]        /* Store tag with data */
    ldg    x2, [x1]        /* Load tag to x2 */
    cfinv  x0              /* Compare and invalidate if mismatch */

ARM64 부팅 과정

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, SpacemiT K1 등의 칩에서 이미 리눅스가 동작합니다.

특권 모드 (Privilege Modes)

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

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

RISC-V CSR (Control and Status Register)

RISC-V는 특권 모드별로 다른 CSR을 사용합니다. M-mode, S-mode, U-mode 각각 접근 가능한 CSR이 정의됩니다.

/* RISC-V CSR 접근 예시 */

/* sstatus 읽기 */
    csrr   t0, sstatus

/* sstatus의 SIE 비트(Set Interrupt Enable) */
    csrs    sstatus, 0x2

/* sstatus의 SIE 비트 클리어 */
    csrc    sstatus, 0x2

/* sbadir 설정 (Supervisor Binary Interface) */
    csrw    sbadir, t0

/* satp (주소 변환 테이블) 설정 - Sv48의 경우 */
    /* PPN[43:0] = 페이지 테이블 물리 프레임 번호 */
    csrw    satp, t0

RISC-V 페이지 테이블 (Sv39/Sv48/Sv57)

RISC-V는 페이지 테이블 체계를 ISA에서 명시하지 않고 Sv39, Sv48, Sv57 등의 "명명 규약"으로 정의합니다. 리눅스는 Sv48 (4-level)을 주로 사용합니다.

• Sv39: 3-level, 512GB 주소 공간 ( Rendem 1GB, 2MB, 4KB)
• Sv48: 4-level, 256TB 주소 공간, 가장 일반적
• Sv57: 5-level, 128PB 주소 공간 ( v6.13, 일부 SoC)

/* arch/riscv/include/asm/pgtable.h - 페이지 테이블 형식 */

#define PTE_SHIFT     10       /* PTE Bits 수 */
#define PTE_PFN_SHIFT 10       /* PFN 시작 비트 */
#define PTE_VALID    _(1 << 0)
#define PTE_READ    _(1 << 1)      /* U=0: Supervisor, U=1: User */
#define PTE_WRITE   _(1 << 2)      /* Write */
#define PTE_EXEC    _(1 << 3)      /* Execute */
#define PTE_USER     _(1 << 4)      /* User accessible */
#define PTE_GLOBAL   _(1 << 5)      /* Global */
#define PTE_ACCESS   _(1 << 6)      /* Accessed */
#define PTE_DIRTY    _(1 << 7)      /* Dirty (Svadu 확장) */

/* Sv48 4-level 페이지 테이블 */
/* VA [47:39] → PML4[511:0] → PDPT[511:0] → PD[511:0] → PT[511:0] → 4KB page */

CLINT와 PLIC (인터럽트 컨트롤러)

RISC-V의 인터럽트는 두 가지 유형으로 나뉩니다:

• CLINT (Core Local Interrupt): Software interrupt (시계열Timer,IPI), 각 코어별
• PLIC (Platform-Level Interrupt Controller): 외부 디바이스 IRQ, 전역

/* drivers/irqchip/irq-sifive-plic.c - PLIC */

/* PLIC IRQ 소스 */
#define PLIC_ENABLE_OFFSET      0x1000
#define PLIC_THRESHOLD_OFFSET 0x200000
#define PLIC_CLAIM_OFFSET       0x200004

/* IRQ 소스 설정 예시 */
static void plic_toggle(struct irq_data *d, unsigned enable)
{
    u32 mask = 1UL << (irq(d) % 32);
    void __iomem *reg = plic_regs + PLIC_ENABLE_OFFSET +
                       (irq(d) / 32) * 4;
    if (enable)
        writel(readl(reg) | mask, reg);
    else
        writel(readl(reg) & ~mask, reg);
}

/* IRQ 클레임 (CLAIM) - 인터럽트 핸들링 */
static void plic_handle_irq(void)
{
    u32 irq;
    while ((irq = readl(plic_regs + PLIC_CLAIM_OFFSET))) {
        generic_handle_domain_irq(irq_domain, irq);
        writel(irq, plic_regs + PLIC_CLAIM_OFFSET);
    }
}

SBI 확장

SBI는 다양한 확장을 정의합니다. 표준 확장 목록:

SBI (Supervisor Binary Interface)

SBI는 S-mode(커널)와 M-mode(펌웨어) 사이의 표준 인터페이스입니다. 리눅스 커널은 SBI 호출을 통해 타이머(Timer) 설정, 프로세서 간 인터럽트(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 부팅 과정

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

특권 레벨 비교 (Privilege Level Comparison)

운영체제가 여러 프로그램을 동시에 실행할 때, 한 프로그램이 다른 프로그램의 메모리를 덮어쓰거나 하드웨어를 직접 제어하면 시스템 전체가 무너집니다. 이를 막기 위해 CPU는 실행 코드가 "얼마나 많은 권한을 갖느냐"를 하드웨어 수준에서 구분합니다 — 이것이 특권 레벨(Privilege Level)입니다.

특권 레벨이 낮은 코드(사용자 애플리케이션)는 직접 하드웨어에 접근하거나 다른 프로세스의 메모리를 읽으려 하면 CPU가 즉시 예외(Exception)를 발생시켜 커널에 제어권을 넘깁니다. 커널은 특권 레벨이 가장 높은 곳에서 실행되며, 이 경계가 OS의 보안과 안정성의 근본입니다. 세 아키텍처는 이 개념을 각기 다른 이름과 계층 수로 구현합니다:

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

• 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 관리, 캐시(Cache) 관리 등 메모리 관련 코드
• 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는 강력한 OoOE(비순서 실행)와 넓은 SIMD 레지스터를 갖추고 있지만, 그 복잡성만큼 잘못된 사용이 성능을 오히려 깎는 경우도 많습니다. 대표적인 함정은 캐시 라인 경계를 무시한 데이터 배치(False Sharing)와, likely()/unlikely() 없이 작성된 분기 코드입니다. 아래 기법들은 "기본값을 지키면 손해 없다"는 관점에서 핵심만 정리한 것입니다.

/* 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(RISC 계열)는 x86와 달리 약한 메모리 순서(Weak Memory Ordering) 모델을 사용합니다. 코드가 작성된 순서와 실제 메모리 접근 순서가 다를 수 있기 때문에, 공유 데이터를 다룰 때는 dmb/dsb 배리어나 smp_wmb()/smp_rmb() 같은 커널 추상화를 명시적으로 사용해야 합니다. 이 점이 x86 경험자가 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 최적화 포인트

RISC-V는 기본 ISA가 단순한 대신 실제 SoC마다 지원하는 확장 집합이 다릅니다. 따라서 최적화 코드를 작성할 때는 런타임에 확장 유무를 확인(riscv_has_extension_likely())한 뒤 분기하는 패턴이 필수입니다. 아직 생태계가 성숙 중인 만큼, 특정 SoC에서만 동작하는 코드가 다른 보드에서 폴백(Fallback)으로 느리게 동작하는 사례를 사전에 방지해야 합니다.

실전 디버깅(Debugging) 팁 (Debugging Tips)

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

공통 디버깅 기법

아키텍처에 상관없이 가장 먼저 활용해야 할 도구는 커널 로그(pr_debug/pr_err)와 WARN_ON() 계열 매크로입니다. 이 두 가지는 별도 장비 없이도 즉시 사용할 수 있고, 문제 발생 위치와 콜스택을 빠르게 좁혀 주기 때문에 항상 첫 번째 수단으로 삼아야 합니다. 아키텍처 특화 도구(JTAG, CoreSight 등)는 그다음 단계입니다.

/* 커널 디버그 출력 */
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 특화 디버깅

x86_64는 Intel PT(Processor Trace)와 MSR 직접 접근이라는 강력한 하드웨어 도구를 제공합니다. Intel PT는 분기 명령 실행 이력을 하드웨어가 기록하므로, 이미 크래시가 발생한 후에도 어떤 경로로 실행되었는지 재구성할 수 있습니다. 일반적인 `printk` 디버깅으로는 타이밍 문제를 재현하기 어려운 경쟁 조건(Race Condition) 디버깅에 특히 유용합니다.

ARM64 특화 디버깅

ARM64 플랫폼은 대부분 임베디드·서버 보드이기 때문에 UART 시리얼 콘솔이 핵심 디버깅 수단입니다. 부팅 초기에 출력이 없다면 earlycon 파라미터로 직렬 포트(Serial Port)를 직접 지정해야 합니다. 칩 내부 트레이스가 필요한 경우에는 CoreSight ETM(Embedded Trace Macrocell)을 활용하며, 이는 Intel PT의 ARM 대응 기능입니다. Device Tree 구성 오류는 /proc/device-tree/와 dtc로 덤프해서 비교하는 것이 가장 빠릅니다.

RISC-V 특화 디버깅

실제 RISC-V 하드웨어 없이 시작하기 가장 좋은 방법은 Spike ISA 시뮬레이터 또는 QEMU RISC-V입니다. 두 환경 모두 커널 부팅 로그를 터미널로 받아볼 수 있으며, 실리콘이 없는 상태에서 SBI·CSR 동작을 검증하는 데 유용합니다. 실제 보드를 사용할 경우, RISC-V JTAG 디버그 스펙은 x86/ARM보다 최근에 정의되었으므로 보드마다 지원 품질이 다릅니다. 보드 문서에서 지원 디버그 Transport(JTAG/cJTAG)를 먼저 확인하세요.

자주 묻는 질문 (FAQ)

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

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

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

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

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)

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

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

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

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

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

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)

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

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) 문서를 참고하세요.

Q8. PREEMPT_RT와 PREEMPT의 차이는 무엇인가요?

A: 두 옵션은 선점(preemption) 범위가 다릅니다:

• CONFIG_PREEMPT — 커널 코드 대부분을 선점할 수 있지만, 스핀락(spinlock) 내부와 같은 임계 구간은 선점 불가능합니다. 일반 데스크탑/서버 환경에 적합합니다.
• CONFIG_PREEMPT_RT (v6.12 메인라인 병합) — 스핀락을 RT-mutex로 변환하고, 인터럽트 핸들러를 스레드화하여 거의 모든 커널 경로를 선점할 수 있습니다. 수십 마이크로초 수준의 결정적 지연(deterministic latency)을 보장하여 산업 제어, 로봇 공학, 프로 오디오 등에 사용됩니다.

v6.12 이전에는 별도의 외부 패치(Patch)(rt-patches)를 적용해야 했으나, 이제 메인라인 커널만으로 실시간(Real-time) 커널을 빌드할 수 있습니다. 자세한 내용은 RT-Mutex 문서를 참고하세요.

Q9. FRED가 기존 IDT를 완전히 대체하나요?

A: FRED(Flexible Return and Event Delivery)는 Intel이 도입한 새로운 이벤트 전달 메커니즘으로, v6.12에서 커널 지원이 추가되었습니다.

• 대체 범위 — FRED는 인터럽트, 예외, 시스템 콜의 진입/복귀 경로를 IDT(Interrupt Descriptor Table) 기반에서 전용 하드웨어 메커니즘으로 대체합니다. 스택 전환, 레지스터 저장, 이벤트 레벨 분류를 하드웨어가 자동으로 처리합니다.
• 호환성 — FRED를 지원하지 않는 프로세서에서는 기존 IDT 방식이 그대로 사용됩니다. 커널은 부팅 시 CPU 기능을 감지하여 자동으로 적절한 경로를 선택합니다.
• 이점 — 커널 진입/복귀 오버헤드 감소, 중첩 이벤트 처리 효율화, SYSRET 관련 보안 취약점(Vulnerability) 경로 제거 등의 장점이 있습니다.

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

매뉴얼 효과적 활용법

AMD vs Intel 마이크로아키텍처 비교 (Microarchitecture Comparison)

x86_64 프로세서를 제조하는 두 벤더 — AMD와 Intel — 는 동일한 ISA(명령어 셋 아키텍처)를 구현하지만, 내부 마이크로아키텍처 설계 철학이 근본적으로 다릅니다. 이 차이는 커널의 스케줄러, NUMA 정책, 캐시 관리, 전력 제어 코드에 직접적인 영향을 미칩니다.

칩렛(Chiplet) vs 모놀리식/타일(Tile) 설계

인터커넥트 토폴로지 비교

파이프라인(Pipeline) 및 실행 엔진 비교

마이크로아키텍처 세대별 파이프라인 폭과 내부 자원의 차이는 IPC(클록당 명령어 수)와 분기 예측 정확도에 직접 영향을 미치며, 커널의 성능 최적화 결정에도 관련됩니다.

x86 CPU 실행 모드 (Operating Modes)

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

모드 전환 흐름

Real Mode (리얼 모드)

Real Mode는 1978년 Intel 8086 설계 당시 유일한 실행 모드였습니다. 당시 메모리는 1MB가 최대였고, 메모리 보호 개념 자체가 없었기 때문에 모든 코드가 하드웨어에 직접 접근할 수 있었습니다. 현대 x86_64 시스템에서 Real Mode는 부팅 직후 펌웨어(BIOS/UEFI) 환경에서만 사용됩니다. CPU가 전원을 켜는 순간에는 하위 호환성을 위해 항상 Real Mode로 시작하고, 이후 Protected Mode → Long Mode 순으로 전환합니다. 즉, 커널 개발자가 Real Mode 코드를 직접 작성할 일은 거의 없지만, 부팅 초기 실패를 디버깅할 때 이 모드의 제약(16비트, 1MB 주소)을 이해하고 있어야 합니다.

; 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 적재를 위한 인라인 함수(Inline Function)를 제공합니다:

/* 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에서 시스템 디스크립터를 위한 구조체(Struct)를 정의합니다:

/* 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: 임의 주소에 로드되어도 내부 참조는 상대 오프셋으로 유효

v6.12~v6.14 최신 변경사항 (Recent Kernel Changes)

커널 v6.12~v6.14(2024년 말~2025년 초)에서 아키텍처 관련 주요 변경사항을 정리합니다. 이 기간에는 PREEMPT_RT 완전 병합, sched_ext, 각 아키텍처의 하드웨어 보안 기능 확장 등 대규모 변경이 이루어졌습니다.

크로스 아키텍처 변경

PREEMPT_RT 완전 메인라인 병합, sched_ext BPF 스케줄러 도입 등 스케줄링 서브시스템의 오랜 숙제가 해결된 시기입니다. NUMA 메모리 코드 범용화처럼 특정 아키텍처에 묶여 있던 코드를 공통 계층으로 올리는 작업도 병행되었습니다.

x86_64 변경

Intel FRED(유연한 이벤트 전달)와 AMD Bus Lock Detect가 핵심 변경입니다. 인터럽트·예외 전달 경로를 현대화하고, 잠금 경합(Lock Contention)으로 인한 성능 저하를 하드웨어 수준에서 감지·제어하는 방향으로 발전하고 있습니다.

ARM64 변경

메모리 보호 키(POE), ARM CCA 기밀 컴퓨팅, GCS 제어 흐름 보호 등 하드웨어 보안 기능 확장이 집중되었습니다. 서버·엣지 시장에서 ARM64의 역할이 커지면서 가상화·신뢰 실행 환경(TEE) 기반 강화도 함께 진행됩니다.

RISC-V 변경

IOMMU 지원, 하드웨어 자동 A/D 비트 갱신(Svade/Svadu), 상위 비트 태그 ABI 등 생태계 성숙을 보여주는 변경들입니다. "확장 집합을 조합해 ISA를 구성한다"는 RISC-V 설계 철학에 따라 매 릴리스마다 새로운 표준 확장이 커널 지원 목록에 추가되고 있습니다.

v6.15~v7.0 최신 변경사항 (2025-2026)

2025년 5월(v6.15)부터 2026년 4월(v7.0)에 이르는 기간은 리눅스 커널이 메이저 버전을 19→7.0으로 변경한 전환점이었습니다. Rust 정식 지원 승격, FRED 확장 준비, CXL+ACPI PRMT 지원 같은 대규모 변경이 이어졌으며, Android Common Kernel도 2026년부터 Trunk Stable(Q2/Q4 릴리스) 모델로 전환합니다.

크로스 아키텍처 변경

Rust가 실험적 지위를 벗어나 C와 대등한 공식 커널 언어로 승격된 것이 이 시기의 가장 큰 변화입니다. 동시에 Linus Torvalds가 메이저 버전 번호를 6에서 7로 올리며 단일 헤드라인 기능보다 장기 프로젝트들의 수렴이 특징인 전환점이 되었습니다.

x86_64 변경

AMD INVLPGB 브로드캐스트 TLB 무효화와 Intel Diamond Rapids/Nova Lake S 지원처럼, 코어 수가 수백 개에 이르는 대형 서버·CXL 확장 메모리 시스템에서 발생하는 확장성(Scalability) 문제를 해결하는 변경들이 주를 이룹니다.

ARM64 변경

Lazy Preemption의 ARM64 정식 도입, SME(행렬 연산 가속), MPAM(메모리 QoS 분할) 등 클라우드·HPC 서버에서 ARM64의 성능과 자원 격리 능력을 끌어올리는 방향으로 집중되고 있습니다.

RISC-V 변경

Zicfiss(Shadow Stack)·Zicfilp(Landing Pad)로 제어 흐름 무결성(CFI) 하드웨어 지원을 완성하고, Tenstorrent AI 가속기 지원을 시작하는 등 RISC-V 생태계가 보안과 AI 영역으로 확장되고 있습니다.

LoongArch / 기타 아키텍처

2026년 하드웨어 지형

아키텍처 분석 플레이북

Kexec 시스템

kexec는 실행 중인 커널에서 다른 커널로 재부팅 없이 전환하는 메커니즘입니다. 재부팅 시간을 획기적으로 단축하며, kdump 기반 크래시 덤프(Dump) 수집에도 사용됩니다.

/* kernel/kexec.c - kexec 핵심 구조체 */

struct kexec_segment {
    void *buf;           /* 버퍼 가상 주소 */
    size_t bufsz;        /* 버퍼 크기 */
    void *mem;            /* 대상 물리 주소 */
    size_t memsz;        /* 대상 메모리 크기 */
};

struct kexec_image {
    unsigned long start;    /* 엔트리 포인트 */
    unsigned long type;    /* 커널 유형 */
    int nr_segments;
    struct kexec_segment segment[];
};

/* kexec 시스템 콜 */
#define KEXEC_LOAD          0x2000
#define KEXEC_EXEC         0x2001
#define KEXEC_UNLOAD       0x2002
#define KEXEC_ARCH         0x2003
#define KEXEC_MODE         0x2004

크래시 덤프 (kdump)

커널 패닉(Kernel Panic) 시 메모리 덤프를 수집하는 메커니즘입니다. 두 번째 커널(kdump 커널)이 패닉을 트리거하고 첫 번째 커널의 메모리를 덤프합니다.

# kdump 설정 예시 (RHEL/CentOS)

# /etc/kdump.conf 설정
path /var/crash
core_collector makedumpfile -c --page-size 4096

# crash 커널 파라미터
crashkernel=256M

# 크래시 덤프 분석
crash vmlinuz-$(uname -r) vmcore

ACPI (Advanced Configuration and Power Interface)

ACPI는 x86/ARM64 서버와 데스크탑에서 하드웨어 구성과 전원 관리를 담당하는 표준 인터페이스입니다. DSDT(ACPI Machine Language)와 SSDT(Secondary System Description Table)로 테이블이 제공됩니다.

/* drivers/acpi/bus.c - ACPI 버스 드라이버 */

static int acpi_bus_init(void)
{
    acpi_status status;

    /* ACPI 테이블 루트 얻기 */
    status = acpi_initialize_tables(initial_table_entry, 4, 0);
    if (ACPI_FAILURE(status))
        return -ENODEV;

    /* ACPI 네임스페이스 로드 (DSDT/SSDT 파싱) */
    status = acpi_load_tables();
    if (ACPI_FAILURE(status))
        return -ENODEV;

    /* ACPI 하드웨어 초기화 */
    status = acpi_enable_subsystem(0);
    return 0;
}

Device Tree Binding

Device Tree는 하드웨어 구성 정보를 구조화된 DTS로 기술합니다. 각 디바이스 드라이버는OF_MATCH_TABLE으로 DT 노드에 바인딩됩니다.

/* drivers/of/device.c - OF 디바이스 매칭 */

static const struct of_device_id irqchip_of_match[] = {
    { .compatible = "arm,gic-v3", .data = gic_of_init },
    { .compatible = "arm,gic-v2", .data = gic_of_init },
    { .compatible = "arm,pl011", .data = pl011_of_init },
    { },
};

/* 드라이버 등록 */
static int __init irqchip_init(void)
{
    return of_platform_populate(NULL, DEFAULT_OF_ROOT,
                         irqchip_of_match, NULL);
}

아키텍처 문서를 읽을 때는 개념 암기보다 "실제 커널 코드에서 어디서 소비되는지"를 함께 확인해야 이해가 빠르게 고정됩니다. 아래 절차는 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

참고자료

• 커널 개발 프로세스 개요 — How the development process works (kernel.org)
• x86 아키텍처 공식 문서 — x86-specific Documentation (kernel.org)
• ARM64 아키텍처 공식 문서 — ARM64 Architecture (kernel.org)
• RISC-V 아키텍처 공식 문서 — RISC-V Architecture (kernel.org)
• 커널 코어 API 문서 — Core API Documentation (kernel.org)
• 커널 초기화 순서 해설 — An introduction to the kernel initialization (LWN.net)
• 커널 소스 구조 개요 — A guide to the Kernel Development Process (LWN.net)
• LWN 커널 인덱스 — LWN.net Kernel Index
• 아키텍처별 커널 소스 — arch/ 디렉터리 (Bootlin Elixir)
• 커널 초기화 진입점 소스 — init/main.c (Bootlin Elixir)
• 커널 부트 파라미터 목록 — The kernel's command-line parameters (kernel.org)
• 커널 빌드 시스템 문서 — Kernel Build System (kernel.org)
• Linux 6.12 릴리스 요약 — KernelNewbies (PREEMPT_RT, sched_ext, FRED)
• Linux 6.13 릴리스 요약 — KernelNewbies (GCS, Lazy preemption, RISC-V IOMMU)
• Linux 6.14 릴리스 요약 — KernelNewbies (TLB 최적화, SpacemiT K1)
• Robert Love — Linux Kernel Development, 3rd Edition, Addison-Wesley (커널 전반 구조와 서브시스템 해설)
• Daniel P. Bovet, Marco Cesati — Understanding the Linux Kernel, 3rd Edition, O'Reilly (x86 중심 커널 내부 구조 상세)

관련 문서

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

• 홈 — 리눅스 커널 소개
• 부팅 과정 — 커널 부팅 과정
• 프로세스 관리 — 프로세스와 태스크 구조체
• 메모리 관리 개요 — 메모리 아키텍처
• 프로세스 스케줄러 — 스케줄러 아키텍처
• CPU 토폴로지 — CPU 아키텍처
• 커널 하드닝 — 아키텍처별 보안 기능 (CET, MTE, PAC, GCS)