Rust로 'Freestanding 실행파일' 만들기

운영체제 커널을 만드는 첫 단계는 표준 라이브러리(standard library)를 링크하지 않는 Rust 실행파일을 만드는 것입니다. 이 실행파일은 운영체제가 없는 bare metal 시스템에서 동작할 수 있습니다.

이 블로그는 GitHub 저장소에서 오픈 소스로 개발되고 있으니, 문제나 문의사항이 있다면 저장소의 ‘Issue’ 기능을 이용해 제보해주세요. 페이지 맨 아래에 댓글을 남기실 수도 있습니다. 이 포스트와 관련된 모든 소스 코드는 저장소의 post-01 브랜치에서 확인하실 수 있습니다.

🔗소개

운영체제 커널을 만드려면 운영체제에 의존하지 않는 코드가 필요합니다. 자세히 설명하자면, 스레드, 파일, 동적 메모리, 네트워크, 난수 생성기, 표준 출력 및 기타 운영체제의 추상화 또는 특정 하드웨어의 기능을 필요로 하는 것들은 전부 사용할 수 없다는 뜻입니다. 우리는 스스로 운영체제 및 드라이버를 직접 구현하려는 상황이니 어찌 보면 당연한 조건입니다.

운영체제에 의존하지 않으려면 Rust 표준 라이브러리의 많은 부분을 사용할 수 없습니다. 그래도 우리가 이용할 수 있는 Rust 언어 자체의 기능들은 많이 남아 있습니다. 예를 들어 반복자, 클로저, 패턴 매칭, option / result, 문자열 포맷 설정, 그리고 소유권 시스템 등이 있습니다. 이러한 기능들은 우리가 커널을 작성할 때 undefined behavior나 메모리 안전성에 대한 걱정 없이 큰 흐름 단위의 코드를 작성하는 데에 집중할 수 있도록 해줍니다.

Rust로 운영체제 커널을 작성하려면, 운영체제 없이도 실행가능한 실행파일이 필요합니다. 이러한 실행파일은 보통 “freestanding 실행파일” 혹은 “bare-metal 실행파일” 이라고 불립니다.

이 포스트에서는 “freestanding 실행 파일” 을 만드는 데 필요한 것들을 여러 단계로 나누고, 각 단계가 왜 필요한지에 대해 설명해드립니다. 중간 과정은 생략하고 그저 최소한의 예제 코드만 확인하고 싶으시면 요약 섹션으로 넘어가시면 됩니다.

🔗Rust 표준 라이브러리 링크 해제하기

모든 Rust 프로그램들은 Rust 표준 라이브러리를 링크하는데, 이 라이브러리는 스레드, 파일, 네트워킹 등의 기능을 제공하기 위해 운영체제에 의존합니다. Rust 표준 라이브러리는 또한 C 표준 라이브러리인 libc에도 의존합니다 (libc는 운영체제의 여러 기능들을 이용합니다). 우리가 운영체제를 직접 구현하기 위해서는 운영체제를 이용하는 라이브러리들은 사용할 수 없습니다. 그렇기에 우선 no_std 속성을 이용해 자동으로 Rust 표준 라이브러리가 링크되는 것을 막아야 합니다.

제일 먼저 아래의 명령어를 통해 새로운 cargo 애플리케이션 크레이트를 만듭니다.

cargo new blog_os --bin --edition 2018

프로젝트 이름은 blog_os 또는 원하시는 이름으로 정해주세요. --bin 인자는 우리가 cargo에게 실행 파일 (라이브러리와 대조됨)을 만들겠다고 알려주고, --edition 2018 인자는 cargo에게 우리가 Rust 2018 에디션을 사용할 것이라고 알려줍니다. 위 명령어를 실행하고 나면, cargo가 아래와 같은 크레이트 디렉토리를 만들어줍니다.

blog_os
├── Cargo.toml
└── src
    └── main.rs

크레이트 설정은 Cargo.toml에 전부 기록해야 합니다 (크레이트 이름, 크레이트 원작자, semantic version 번호, 의존 라이브러리 목록 등). src/main.rs 파일에 크레이트 실행 시 맨 처음 호출되는 main 함수를 포함한 중추 모듈이 있습니다. cargo build 명령어를 통해 크레이트를 빌드하면 target/debug 디렉토리에 blog_os 실행파일이 생성됩니다.

🔗no_std 속성

현재 우리가 만든 크레이트는 암시적으로 Rust 표준 라이브러리를 링크합니다. 아래와 같이 [no_std 속성]을 이용해 더 이상 표준 라이브러리가 링크되지 않게 해줍니다.

// main.rs

#![no_std]

fn main() {
    println!("Hello, world!");
}

이제 cargo build 명령어를 다시 실행하면 아래와 같은 오류 메세지가 뜰 것입니다:

error: cannot find macro `println!` in this scope
 --> src/main.rs:4:5
  |
4 |     println!("Hello, world!");
  |     ^^^^^^^

이 오류가 뜨는 이유는 println 매크로를 제공하는 Rust 표준 라이브러리를 우리의 크레이트에 링크하지 않게 되었기 때문입니다. println은 표준 입출력 (운영체제가 제공하는 특별한 파일 서술자)으로 데이터를 쓰기 때문에, 우리는 이제 println을 이용해 메세지를 출력할 수 없습니다.

println 매크로 호출 코드를 지운 후 크레이트를 다시 빌드해봅시다.

// main.rs

#![no_std]

fn main() {}

> cargo build
error: `#[panic_handler]` function required, but not found
error: language item required, but not found: `eh_personality`

오류 메세지를 통해 컴파일러가 #[panic_handler] 함수와 language item 을 필요로 함을 확인할 수 있습니다.

🔗패닉 (Panic) 시 호출되는 함수 구현하기

컴파일러는 패닉이 일어날 경우 panic_handler 속성이 적용된 함수가 호출되도록 합니다. 표준 라이브러리는 패닉 시 호출되는 함수가 제공되지만, no_std 환경에서는 우리가 패닉 시 호출될 함수를 직접 설정해야 합니다.

// in main.rs

use core::panic::PanicInfo;

/// 패닉이 일어날 경우, 이 함수가 호출됩니다.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

PanicInfo 인자는 패닉이 일어난 파일명, 패닉이 파일 내 몇 번째 줄에서 일어났는지, 그리고 패닉시 전달된 메세지에 대한 정보를 가진 구조체입니다. 위 panic 함수는 절대로 반환하지 않기에 “never” 타입 !을 반환하도록 적어 컴파일러에게 이 함수가 반환 함수임을 알립니다. 당장 이 함수에서 우리가 하고자 하는 일은 없기에 그저 함수가 반환하지 않도록 무한루프를 넣어줍니다.

🔗eh_personality Language Item

Language item은 컴파일러가 내부적으로 요구하는 특별한 함수 및 타입들을 가리킵니다. 예를 들어 Copy 트레잇은 어떤 타입들이 copy semantics 를 가지는지 컴파일러에게 알려주는 language item 입니다. Copy 트레잇이 구현된 코드에 있는 #[lang = "copy"] 속성을 통해 이 트레잇이 language item으로 선언되어 있음을 확인할 수 있습니다.

임의로 구현한 language item을 사용할 수는 있지만, 위험할 수도 있기에 주의해야 합니다. 그 이유는 language item의 구현 코드는 매우 자주 변경되어 불안정하며, language item에 대해서 컴파일러가 타입 체크 조차 하지 않습니다 (예시: language item 함수의 인자 타입이 정확한지 조차 체크하지 않습니다). 임의로 구현한 language item을 이용하는 것보다 더 안정적으로 위의 language item 오류를 고칠 방법이 있습니다.

eh_personality language item은 스택 되감기 (stack unwinding)을 구현하는 함수를 가리킵니다. 기본적으로 Rust는 패닉이 일어났을 때 스택 되감기를 통해 스택에 살아있는 각 변수의 소멸자를 호출합니다. 이를 통해 자식 스레드에서 사용 중이던 모든 메모리 리소스가 반환되고, 부모 스레드가 패닉에 대처한 후 계속 실행될 수 있게 합니다. 스택 되감기는 복잡한 과정으로 이루어지며 운영체제마다 특정한 라이브러리를 필요로 하기에 (예: Linux는 libunwind, Windows는 structured exception handling), 우리가 구현할 운영체제에서는 이 기능을 사용하지 않을 것입니다.

🔗스택 되감기를 해제하는 방법

스택 되감기가 불필요한 상황들이 여럿 있기에, Rust 언어는 패닉 시 실행 종료 할 수 있는 선택지를 제공합니다. 이는 스택 되감기에 필요한 심볼 정보 생성을 막아주어 실행 파일의 크기 자체도 많이 줄어들게 됩니다. 스택 되감기를 해제하는 방법은 여러가지 있지만, 가장 쉬운 방법은 Cargo.toml 파일에 아래의 코드를 추가하는 것입니다.

[profile.dev]
panic = "abort"

[profile.release]
panic = "abort"

위의 코드를 통해 dev 빌드 (cargo build 실행)와 release 빌드 (cargo build --release 실행) 에서 모두 패닉 시 실행이 종료되도록 설정되었습니다. 이제 더 이상 컴파일러가 eh_personality language item을 필요로 하지 않습니다.

위에서 본 오류들을 고쳤지만, 크레이트를 빌드하려고 하면 새로운 오류가 뜰 것입니다:

> cargo build
error: requires `start` lang_item

우리의 프로그램에는 프로그램 실행 시 최초 실행 시작 지점을 지정해주는 start language item이 필요합니다.

🔗start 속성

혹자는 프로그램 실행 시 언제나 main 함수가 가장 먼저 호출된다고 생각할지도 모릅니다. 대부분의 프로그래밍 언어들은 런타임 시스템을 가지고 있는데, 이는 가비지 컬렉션 (예시: Java) 혹은 소프트웨어 스레드 (예시: GoLang의 goroutine) 등의 기능을 담당합니다. 이러한 런타임 시스템은 프로그램 실행 이전에 초기화 되어야 하기에 main 함수 호출 이전에 먼저 호출됩니다.

러스트 표준 라이브러리를 링크하는 전형적인 러스트 실행 파일의 경우, 프로그램 실행 시 C 런타임 라이브러리인 crt0 (“C runtime zero”) 에서 실행이 시작됩니다. crt0는 C 프로그램의 환경을 설정하고 초기화하는 런타임 시스템으로, 스택을 만들고 프로그램에 주어진 인자들을 적절한 레지스터에 배치합니다. crt0가 작업을 마친 후 start language item으로 지정된 Rust 런타임의 실행 시작 함수를 호출합니다. Rust는 최소한의 런타임 시스템을 가지며, 주요 기능은 스택 오버플로우 가드를 초기화하고 패닉 시 역추적 (backtrace) 정보를 출력하는 것입니다. Rust 런타임의 초기화 작업이 끝난 후에야 main 함수가 호출됩니다.

우리의 “freestanding 실행 파일” 은 Rust 런타임이나 crt0에 접근할 수 없기에, 우리가 직접 프로그램 실행 시작 지점을 지정해야 합니다. crt0가 start language item을 호출해주는 방식으로 동작하기에, start language item을 구현하고 지정하는 것만으로는 문제를 해결할 수 없습니다. 대신 우리가 직접 crt0의 시작 지점을 대체할 새로운 실행 시작 지점을 제공해야 합니다.

🔗실행 시작 지점 덮어쓰기

#![no_main] 속성을 이용해 Rust 컴파일러에게 우리가 일반적인 실행 시작 호출 단계를 이용하지 않겠다고 선언합니다.

#![no_std]
#![no_main]

use core::panic::PanicInfo;

/// 패닉이 일어날 경우, 이 함수가 호출됩니다.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

main 함수가 사라진 것을 눈치채셨나요? main 함수를 호출해주는 런타임 시스템이 없는 이상 main 함수의 존재도 더 이상 의미가 없습니다. 우리는 운영체제가 호출하는 프로그램 실행 시작 지점 대신 우리의 새로운 _start 함수를 실행 시작 지점으로 대체할 것입니다.

#[no_mangle]
pub extern "C" fn _start() -> ! {
    loop {}
}

#[no_mangle] 속성을 통해 name mangling을 해제하여 Rust 컴파일러가 _start 라는 이름 그대로 함수를 만들도록 합니다. 이 속성이 없다면, 컴파일러가 각 함수의 이름을 고유하게 만드는 과정에서 이 함수의 실제 이름을 _ZN3blog_os4_start7hb173fedf945531caE 라는 이상한 이름으로 바꿔 생성합니다. 우리가 원하는 실제 시작 지점 함수의 이름을 정확히 알고 있어야 링커 (linker)에도 그 이름을 정확히 전달할 수 있기에 (후속 단계에서 진행) #[no_mangle] 속성이 필요합니다.

또한 우리는 이 함수에 extern "C"라는 표시를 추가하여 이 함수가 Rust 함수 호출 규약 대신에 C 함수 호출 규약을 사용하도록 합니다. 함수의 이름을 _start로 지정한 이유는 그저 런타임 시스템들의 실행 시작 함수 이름이 대부분 _start이기 때문입니다.

! 반환 타입은 이 함수가 발산 함수라는 것을 의미합니다. 시작 지점 함수는 오직 운영체제나 부트로더에 의해서만 직접 호출됩니다. 따라서 시작 지점 함수는 반환하는 대신 운영체제의 exit 시스템콜을 이용해 종료됩니다. 우리의 “freestanding 실행 파일” 은 실행 종료 후 더 이상 실행할 작업이 없기에, 시작 지점 함수가 작업을 마친 후 기기를 종료하는 것이 합리적입니다. 여기서는 일단 ! 타입의 조건을 만족시키기 위해 무한루프를 넣어 줍니다.

다시 cargo build를 실행하면, 끔찍한 링커 오류를 마주하게 됩니다.

🔗링커 오류

링커는 컴파일러가 생성한 코드들을 묶어 실행파일로 만드는 프로그램입니다. 실행 파일 형식은 Linux, Windows, macOS 마다 전부 다르기에 각 운영체제는 자신만의 링커가 있고 링커마다 다른 오류 메세지를 출력할 것입니다. 오류가 나는 근본적인 원인은 모두 동일한데, 링커는 주어진 프로그램이 C 런타임 시스템을 이용할 것이라고 가정하는 반면 우리의 크레이트는 그렇지 않기 때문입니다.

이 링커 오류를 해결하려면 링커에게 C 런타임을 링크하지 말라고 알려줘야 합니다. 두 가지 방법이 있는데, 하나는 링커에 특정 인자들을 주는 것이고, 또다른 하나는 크레이트 컴파일 대상 기기를 bare metal 기기로 설정하는 것입니다.

🔗Bare Metal 시스템을 목표로 빌드하기

기본적으로 Rust는 당신의 현재 시스템 환경에서 실행할 수 있는 실행파일을 생성하고자 합니다. 예를 들어 Windows x86_64 사용자의 경우, Rust는 x86_64 명령어 셋을 사용하는 .exe 확장자 실행파일을 생성합니다. 사용자의 기본 시스템 환경을 “호스트” 시스템이라고 부릅니다.

여러 다른 시스템 환경들을 표현하기 위해 Rust는 target triple이라는 문자열을 이용합니다. 현재 호스트 시스템의 target triple이 궁금하시다면 rustc --version --verbose 명령어를 실행하여 확인 가능합니다.

rustc 1.35.0-nightly (474e7a648 2019-04-07)
binary: rustc
commit-hash: 474e7a6486758ea6fc761893b1a49cd9076fb0ab
commit-date: 2019-04-07
host: x86_64-unknown-linux-gnu
release: 1.35.0-nightly
LLVM version: 8.0

위의 출력 내용은 x86_64 Linux 시스템에서 얻은 것입니다. 호스트 target triple이 x86_64-unknown-linux-gnu으로 나오는데, 이는 CPU 아키텍쳐 정보 (x86_64)와 하드웨어 판매자 (unknown), 운영체제 (linux) 그리고 응용 프로그램 이진 인터페이스 (ABI) (gnu) 정보를 모두 담고 있습니다.

우리의 호스트 시스템 triple을 위해 컴파일하는 경우, Rust 컴파일러와 링커는 Linux나 Windows와 같은 운영체제가 있다고 가정하고 또한 운영체제가 C 런타임 시스템을 사용할 것이라고 가정하기 때문에 링커 오류 메세지가 출력된 것입니다. 이런 링커 오류를 피하려면 운영체제가 없는 시스템 환경에서 코드가 구동하는 것을 목표로 컴파일해야 합니다.

운영체제가 없는 bare metal 시스템 환경의 한 예시로 thumbv7em-none-eabihf target triple이 있습니다 (이는 임베디드 ARM 시스템을 가리킵니다). Target triple의 none은 시스템에 운영체제가 동작하지 않음을 의미하며, 이 target triple의 나머지 부분의 의미는 아직 모르셔도 괜찮습니다. 이 시스템 환경에서 구동 가능하도록 컴파일하려면 rustup에서 해당 시스템 환경을 추가해야 합니다.

rustup target add thumbv7em-none-eabihf

위 명령어를 실행하면 해당 시스템을 위한 Rust 표준 라이브러리 및 코어 라이브러리를 설치합니다. 이제 해당 target triple을 목표로 하는 freestanding 실행파일을 만들 수 있습니다.

cargo build --target thumbv7em-none-eabihf

--target 인자를 통해 우리가 해당 bare metal 시스템을 목표로 크로스 컴파일할 것이라는 것을 cargo에게 알려줍니다. 목표 시스템 환경에 운영체제가 없는 것을 링커도 알기 때문에 C 런타임을 링크하려고 시도하지 않으며 이제는 링커 에러 없이 빌드가 성공할 것입니다.

우리는 이 방법을 이용하여 우리의 운영체제 커널을 빌드해나갈 것입니다. 위에서 보인 thumbv7em-none-eabihf 시스템 환경 대신 bare metal x86_64 시스템 환경을 묘사하는 커스텀 시스템 환경을 설정하여 빌드할 것입니다. 더 자세한 내용은 다음 포스트에서 더 설명하겠습니다.

🔗링커 인자

Bare metal 시스템을 목표로 컴파일하는 대신, 링커에게 특정 인자들을 추가로 주어 링커 오류를 해결하는 방법도 있습니다. 이 방법은 앞으로 우리가 작성해나갈 커널 코드를 빌드할 때는 사용하지 않을 것이지만, 더 알고싶어 하실 분들을 위해서 이 섹션을 준비했습니다. 아래의 “링커 인자” 텍스트를 눌러 이 섹션의 내용을 확인하세요.

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: /usr/lib/gcc/../x86_64-linux-gnu/Scrt1.o: In function `_start':
          (.text+0x12): undefined reference to `__libc_csu_fini'
          /usr/lib/gcc/../x86_64-linux-gnu/Scrt1.o: In function `_start':
          (.text+0x19): undefined reference to `__libc_csu_init'
          /usr/lib/gcc/../x86_64-linux-gnu/Scrt1.o: In function `_start':
          (.text+0x25): undefined reference to `__libc_start_main'
          collect2: error: ld returned 1 exit status

cargo rustc -- -C link-arg=-nostartfiles

error: linking with `link.exe` failed: exit code: 1561
  |
  = note: "C:\\Program Files (x86)\\…\\link.exe" […]
  = note: LINK : fatal error LNK1561: entry point must be defined

cargo rustc -- -C link-arg=/ENTRY:_start

error: linking with `link.exe` failed: exit code: 1221
  |
  = note: "C:\\Program Files (x86)\\…\\link.exe" […]
  = note: LINK : fatal error LNK1221: a subsystem can't be inferred and must be
          defined

cargo rustc -- -C link-args="/ENTRY:_start /SUBSYSTEM:console"

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: ld: entry point (_main) undefined. for architecture x86_64
          clang: error: linker command failed with exit code 1 […]

cargo rustc -- -C link-args="-e __start"

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: ld: dynamic main executables must link with libSystem.dylib
          for architecture x86_64
          clang: error: linker command failed with exit code 1 […]

cargo rustc -- -C link-args="-e __start -static"

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: ld: library not found for -lcrt0.o
          clang: error: linker command failed with exit code 1 […]

cargo rustc -- -C link-args="-e __start -static -nostartfiles"

# in .cargo/config.toml

[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-arg=-nostartfiles"]

[target.'cfg(target_os = "windows")']
rustflags = ["-C", "link-args=/ENTRY:_start /SUBSYSTEM:console"]

[target.'cfg(target_os = "macos")']
rustflags = ["-C", "link-args=-e __start -static -nostartfiles"]

🔗요약

아래와 같은 최소한의 코드로 “freestanding” Rust 실행파일을 만들 수 있습니다:

src/main.rs:

#![no_std] // Rust 표준 라이브러리를 링크하지 않도록 합니다
#![no_main] // Rust 언어에서 사용하는 실행 시작 지점 (main 함수)을 사용하지 않습니다

use core::panic::PanicInfo;

#[no_mangle] // 이 함수의 이름을 mangle하지 않습니다
pub extern "C" fn _start() -> ! {
    // 링커는 기본적으로 '_start' 라는 이름을 가진 함수를 실행 시작 지점으로 삼기에,
    // 이 함수는 실행 시작 지점이 됩니다
    loop {}
}

/// 패닉이 일어날 경우, 이 함수가 호출됩니다.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

Cargo.toml:

[package]
name = "crate_name"
version = "0.1.0"
authors = ["Author Name <author@example.com>"]

# `cargo build` 실행 시 이용되는 빌드 설정
[profile.dev]
panic = "abort" # 패닉 시 스택 되감기를 하지 않고 바로 프로그램 종료

# `cargo build --release` 실행 시 이용되는 빌드 설정
[profile.release]
panic = "abort" # 패닉 시 스택 되감기를 하지 않고 바로 프로그램 종료

이 실행 파일을 빌드하려면, thumbv7em-none-eabihf와 같은 bare metal 시스템 환경을 목표로 컴파일해야 합니다:

cargo build --target thumbv7em-none-eabihf

또다른 방법으로, 각 호스트 시스템마다 추가적인 링커 인자들을 전달해주어 호스트 시스템 환경을 목표로 컴파일할 수도 있습니다:

# Linux
cargo rustc -- -C link-arg=-nostartfiles
# Windows
cargo rustc -- -C link-args="/ENTRY:_start /SUBSYSTEM:console"
# macOS
cargo rustc -- -C link-args="-e __start -static -nostartfiles"

주의할 것은 이것이 정말 최소한의 freestanding Rust 실행 파일이라는 것입니다. 실행 파일은 여러 가지 조건들을 가정하는데, 그 예로 실행파일 동작 시 _start 함수가 호출될 때 스택이 초기화되어 있을 것을 가정합니다. 이 freestanding 실행 파일을 이용해 실제로 유용한 작업을 처리하려면 아직 더 많은 코드 구현이 필요합니다.

🔗다음 단계는 무엇일까요?

다음 포스트에서는 우리의 freestanding 실행 파일을 최소한의 기능을 갖춘 운영체제 커널로 만드는 과정을 단게별로 설명할 것입니다. 예시로 커스텀 시스템 환경을 설정하는 방법, 우리의 실행 파일을 부트로더와 합치는 방법, 그리고 화면에 메세지를 출력하는 방법 등에 대해 다루겠습니다.