Rust OS 개발일지2

Layfort·2024년 1월 10일
OSOperating SystemRust개발일지운영체제

A Minimal Rust Kernel

  • 저번 시간에 우리는, OS-independent Rust 코드를 작성하는 방법을 배웠다.
  • 이제, 이것을 기반으로 하여 최소기능으로 동작하는 Rust 커널을 만들어보자.

Booting

  • 컴퓨터의 전원을 켜면, 가장 먼저 수행되는 일은 Motherboard의 ROM에 저장되어있는 펌웨어 코드를 실행하는 것이다. → 이 코드는 몇가지 테스트(기기 안정성을 위해)를 진행하고, RAM을 확인한 다음, CPU를 비롯한 하드웨어의 초기화를 진행한다. 그리고 마지막으로 부트로더를 실행한다.

  • 일반적으로 POST + BootLoader가 합쳐진 코드를 Motherboard의 fimrware 코드라고 하고, 이 firmware는 크게 두가지로 나뉜다.

    • BIOS(Basic Input/Output System): IBM PC 호환 기기에서 사용되는 펌웨어
    • UEFI(Unified Extensible Firmware Interface): BIOS의 후속 버전으로, 최근에는 대부분의 컴퓨터에서 사용되고 있다.

  • 본 구현에서는 BIOS만 지원할 예정이다. UEFI를 지원하고자 한다면 다음의 Github Issue

BIOS boot process

  • UEFI 표준을 사용하는 기기들도, 일단은 BIOS를 지원하기 때문에, 실질적으로 BIOS를 사용하면 모든 x86 시스템에서는 부팅을 시킬 수 있다.

    • 사실 이 부분은 현대에 들어서 단점으로 지목받는 부분이기도 하다.
    • 최신 기기들 뿐만 아니라 구식 기기들도 지원하기 위해서 부팅 전에는 CPU를 16-bit(!)로 설정하고 있기 때문이다.(real mode)

  • 잡설은 여기까지하고... 진짜 부팅과정을 살펴보면 다음과 같다.

    1. BIOS 이미지 로딩
    • Motherboard의 ROM에 저장되어있는 BIOS 이미지를 RAM으로 복사한다.
    • 이미지란?: 특정 매체에 저장된 데이터 전체를 하나의 파일로 만든 것.
    1. POST + Hardware initialization
    • POST를 진행하고, 하드웨어를 초기화한다.
    1. Boot Loader 로딩
    • 부트로더를 디스크로부터 RAM으로 복사한다.
    • 일반적으로 부트로더는 디스크의 첫번째 섹터(512Byte)에 저장된다.
    • 하지만, 현대의 대부분의 부트로더는 더 많은 기능을 제공하기 위해, 디스크의 여러 섹터에 저장된다.
      • 이 경우, 첫번째 로더는 두번째 로더를 로드하고, 두번째 로더는 세번째 로더를 로드하는 식으로 진행된다.
    • 이러한 부트로더를 Multi-stage Boot Loader라고 한다.
    1. Boot Loader 실행
    • 부트로더는 커널을 디스크로부터 RAM으로 복사한다.
    • 이 과정에서, Bootlader를 실행하기 위해서 16-bit 모드(real mode)로 설정된 CPU를 32-bit 모드(protected mode)로 설정한다. 그리고, 커널을 실행하기 위해서는 64-bit 모드(long mode)로 설정해야한다.
    • 마지막으로 커널이 필요로 하는 정보를 커널에 전달하고, 커널을 실행한다.

  • Bootloader를 프로그래밍 하는 일은 쉬운일이 아니다.

    • 거의 대부분의 어셈블리로 작성되어있기 때문이다.
    • 그래서, 우리는 Bootloader를 직접 작성하지 않고, bootimage라는 도구를 사용할 것이다.

Multiboot

  • 만일, 운영체제들이 각기 다른 부트로더를 사용한다면, 운영체제를 설치할 때마다 부트로더를 설치해야한다.

    • 이는 매우 번거로운 일이다.
    • 그래서, GNU는 부트로더를 표준화하기 위한 프로젝트를 진행하였고, 그 결과로 Multiboot라는 표준이 만들어졌다.
      • 가장 대표적인 Multiboot 부트로더는 GNU GRUB이다.
    • 이 표준을 따르는 부트로더는, 커널을 로드하기 위한 정보를 커널에게 전달한다.
      • 이 정보를 통해, 커널은 부트로더가 제공하는 기능을 사용할 수 있다.
      • 예를 들어, 커널은 부트로더가 제공하는 메모리 할당 기능을 사용하여, 커널이 사용할 메모리를 할당할 수 있다.
    • Multiboot을 지원하고자 한다면, Multiboot 헤더를 삽입하면 된다.

  • 그러나... Multiboot 역시 몇가지 단점을 가지고 있다.

    • 오직 32비트 protected mode만을 지원합니다. 64비트 long mode를 이용하고 싶다면 CPU 설정을 별도로 변경해주어야 합니다.
    • Multiboot 표준 및 GRUB은 부트로더 구현의 단순화를 우선시하여 개발되었기에, 이에 호응하는 커널 측의 구현이 번거로워진다는 단점이 있습니다. 예를 들어, GRUB이 Multiboot 헤더를 제대로 찾을 수 있으려면 커널 측에서 조정된 기본 페이지 크기 (adjusted default page size)를 링크하는 것이 강제됩니다. 또한, 부트로더가 커널로 전달하는 부팅 정보는 적절한 추상 레벨에서 표준화된 형태로 전달되는 대신 하드웨어 아키텍처마다 상이한 형태로 제공됩니다.
    • GRUB 및 Multiboot 표준에 대한 문서화 작업이 덜 되어 있습니다.
    • GRUB이 호스트 시스템에 설치되어 있어야만 커널 파일로부터 부팅 가능한 디스크 이미지를 만들 수 있습니다. 이 때문에 Windows 및 Mac에서는 부트로더를 개발하는 것이 Linux보다 어렵습니다.

Minimal Rust Kernel

  • 이제 부팅이 뭔지를 알았으니, 우리의 다음 목표는 컴퓨터를 부팅시킬 수 있도록 우리의 freestanding Rust file을 수정하는 것이다.
    • 이전 시간까지의 우리의 작업을 요약하자면, cargo system의 OS 및 system dependency를 제거하고, 새로운 시작점을 정의하는 작업이었다.

Define Compile Target

  • 이전 시간에, 우리는 일단 임시로 우리의 컴파일 대상을 thumbv7em-none-eabihf라는 bare-metal target으로 설정하였다.
    • 이는 ARM Cortex-M3 CPU를 위한 target이다.
    • 이 target은 우리가 지금까지 작성한 코드를 컴파일할 수 있도록 해주었다.
    • 하지만, 이 target은 우리가 만들고자 하는 커널은 x86_64 CPU를 대상으로 하고 있기 때문에, 이 target은 적합하지 않으므로, 새로운 target-triple을 정의해야한다.
  • 일반적으로 rust는 compile target에 대한 정보를 JSON 형식으로 저장한다.
    • e.g. x86_64-unknown-linux-gnu 환경에 대한 정보는 다음과 같다.
    {
  "llvm-target": "x86_64-unknown-linux-gnu",
  "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
  "arch": "x86_64",
  "target-endian": "little",
  "target-pointer-width": "64",
  "target-c-int-width": "32",
  "os": "linux",
  "executables": true,
  "linker-flavor": "gcc",
  "pre-link-args": ["-m64"],
  "morestack": false
}
    • 우리의 목표는 특정 OS가 아닌, bare-metal 환경을 위한 target을 정의하는 것이므로, os 필드는 none으로, arch 필드를 x86_64로 설정하면 된다.
    {
  "llvm-target": "x86_64-unknown-none",
  "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128",
  "arch": "x86_64",
  "target-endian": "little",
  "target-pointer-width": "64",
  "target-c-int-width": "32",
  "os": "none",
  "executables": true,
  "linker-flavor": "ld.lld",
  "linker": "rust-lld",
  "panic-strategy": "abort",
  "disable-redzone": true,
  "features": "-mmx,-sse,+soft-float"
}
    • llvm target: LLVM에서 사용하는 target triple
    • arch: CPU 아키텍처
    • target-endian: CPU의 endian(Big or Little)
    • target-pointer-width: 포인터의 크기(사실상 n-bit system의 n)
    • target-c-int-width: C의 int 타입의 크기
    • os: 운영체제
    • linker-flavor: 링커의 종류
      • linux에서는 기본적으로 gcc를 사용하므로, ld.lld를 사용하도록 설정
    • linker: 링커의 이름
      • rust에서 제공하는 링커(rust-lld)를 사용하도록 설정
    • panic-strategy: panic! 매크로가 호출되었을 때, 어떻게 동작할 것인지를 결정
      • 우리의 커널의 경우에는 stack unwinding을 지원하지 않기 때문에, abort를 선택
    • disable-redzone: redzone을 비활성화할 것인지를 결정
      • redzone: 다른 함수를 호출하지 않는 함수에 대해서, 스택 프레임을 조정하지 않고, 스택프레임의 끝에 128Byte의 공간을 할당하는 기법
      • 이 기법은 함수 호출시에 스택 프레임을 조정하는 비용을 줄여준다.
      • 하지만, interrupt 발생시, handler가 호출되는데, 이때, redzone에 할당되어있는 스택 프레임을 사용하게 되면, 데이터가 덮어씌워지는 문제가 발생한다.
    • features: CPU의 특정 기능을 사용할 것인지를 결정
      • mmx, sse: SIMD 연산을 사용할 것인지를 결정
        • 커널에서는 SIMD 연산을 사용하지 않으므로, 비활성화
        • SIMD 연산의 경우에는 특정 연산의 경우에는 속도를 향상시켜주지만, 커널의 경우에는 그 특정 연산을 사용할 일이 거의 없을 뿐만 아니라, 자주 interrupt가 발생하는 커널의 특성상, SIMD 연산을 사용하면 성능이 저하될 수 있다.
        • 당연하겠지만, 커널에서만 SIMD 연산을 사용하지 않는 것이다. 우리의 커널 위에서 동작하는 프로그램은 SIMD 연산을 사용할 수 있어야한다.
      • soft-float: floating point 연산을 소프트웨어로 처리할 것인지를 결정
        • x86_64에서는 floating point 연산을 기본적으로 SIMD 레지스터를 사용하여 처리한다.
        • 하지만, 위에서 이야기한 것처럼, 커널에서는 SIMD 레지스터를 사용하는 것은 지양해야한다.
        • 따라서 우리는 일반 정수 계산만을 이용해 부동소수점 계산을 소프트웨어 단에서 모방하기 위해서 soft-float를 활성화한다.

Build Kernel

  • 이전 시간까지 진행하였다면, 현재 main.rs 파일은 다음과 같을 것이다.
// src/main.rs

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

use core::panic::PanicInfo;

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

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

  • 이제, build target에 대한 정보를 cargo에게 전달하기 위해, project root directory에 x86-64.json파일을 만들고 여기에 우리의 target(x86_64-unknown-none)에 대한 정보를 저장한다.

  • 여기까지 되었다면, cargo에 우리가 만든 JSON파일을 전달함을 통해서 성공적으로 빌드할 수 있다.

> cargo build --target x86_64.json
  error[E0463]: can't find crate for `core`
  • 하지만 아직 빌드가 되지 않는다. 이는 우리가 core라는 crate를 찾을 수 없기 때문이다.
    • core crate는 Rust의 언어적인 기능을 제공하는 crate이다.
    • 문제는 core crate가 미리 컴파일된 상태로 rustc와 같이 배포된다는 것이다. 따라서, 일반적인 target triple을 사용하는 경우에는 core crate를 별도로 빌드할 필요가 없지만, 지금과 같이 새로운 target에 대해서 빌드를 진행할 경우에는 core crate를 별도로 빌드해야한다.

Build-std feature

  • 이제 core crate를 빌드하기 위해서 build-std를 이용해야만 한다.

    • 이 기능은 rustc와 같이 제공된 core나 다른 표준 라이브러리의 빌드를 사용하는 것이 아니라, 빌드시에 해당 crate들을 직점 재컴파일하는 기능이다.
    • 이 기능의 경우에는, 일반적인 rustc에서는 제공되지 않을 수 있으므로, nightly 버전의 rust를 사용하는 것을 권장한다.

  • build-std를 사용하기 위해서는, cargo 설정 파일(.cargo/config.toml)에 다음과 같이 추가해주면 된다.

# .cargo/config.toml 에 들어갈 내용

[unstable]
build-std = ["core", "compiler_builtins"]

  • 아마 대부분의 경우에는 .cargo폴더가 없을 것이다. 이 경우에는 직접 만들어주면 된다.

  • 이 설정을 통해서, core와 compiler_builtins crate를 새로 컴파일하도록 설정하였다.

  • 만일 compiler_builtins crate 사용에 문제가 있다면, rust-src component를 설치해주면 된다.

    • rustup component add rust-src

  • 여기까지 되었다면, 다음과 같이 빌드가 성공적으로 진행될 것이다.

> cargo build --target x86-64.json
   Compiling core v0.0.0 (/home/bae/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
   Compiling compiler_builtins v0.1.103
   Compiling rustc-std-workspace-core v1.99.0 (/home/bae/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
   Compiling rust_os v0.1.0 (/home/bae/Github/rust_os)
    Finished dev [unoptimized + debuginfo] target(s) in 4.85s
  • build-std를 사용하였기에, 컴파일러가 core와 compiler_builtins crate를 컴파일하는 것을 확인할 수 있다.

Memory built-in functions

  • Rust는 놀랍게도 몇가지 built-in function에 대해서는 system의 c라이브러리에 의존하고 있다.

    • memset, memcpy, memcmp 등의 함수들이 그렇다.

  • 하지만, 우리의 커널은 c라이브러리를 제공할 수 없다.(당연하다. bare-metal 환경이니까)

    • 따라서 우리는 C라이브러리를 링크할 수 없기 떄문에 다른 방법을 찾아야한다.
    1. 직접 구현 + #[no_mangle]
    • 이 방법은 간단하다. 직접 구현하면 된다.
    • 하지만 이 방법의 경우 우리가 직접 구현한 함수 로직에 아주 작은 실수만 있어도 undefined behavior를 일으킬 수 있기에 위험하다.
    • e.g. for문의 구현이 내부적으로 trait 함수인 IntoIterator::into_iter를 호출하고 이 함수가 다시 memcpy 를 호출할 수도 있다. 따라서 충분히 검증된 기존의 함수를 사용하는 것이 좋다.
    1. compiler_builtins crate의 기본제공 함수를 사용

    • 이 crate는 memcpy, memset, memcmp 등의 함수를 제공한다.

    • 다만, libc의 함수들과 충돌할 수 있으므로, 평시에는 사용하지 않도록 해제되어있던 것이다.

    • 따라서, 이 crate의 함수를 사용하기 위해서는 compiler_builtins crate를 사용하도록 설정해주어야한다.

      # .cargo/config.toml 에 들어갈 내용

[unstable]
build-std-features = ["compiler-builtins-mem"]
build-std = ["core", "compiler_builtins"]

  • 현재 우리의 커널은 정말 아무것도 하지 않는다.

    • 이제 우리의 커널이 무언가를 하도록 만들어보자.
    • 먼저, 우리의 커널이 무언가를 출력할 수 있도록 만들어보자.

  • 이를 위해서는 VGA Text Buffer를 사용해야 한다.

    • 이게 뭔지는 다음 시간에 알아보자.

  • 일단, 코드를 보고, 어떻게 동작하는지를 이해해보자.

static HELLO: &[u8] = b"Hello World!";

#[no_mangle]
pub extern "C" fn _start() -> ! {
    let vga_buffer = 0xb8000 as *mut u8;

    for (i, &byte) in HELLO.iter().enumerate() {
        unsafe {
            *vga_buffer.offset(i as isize * 2) = byte;
            *vga_buffer.offset(i as isize * 2 + 1) = 0xb;
        }
    }

    loop {}
}
  • 일단, 정수 0xb8000을 포인터로 캐스팅하여, vga_buffer라는 이름의 포인터를 만들었다.
  • 다음으로 HELLO라는 static 변수에서 문자열을 가져와서, vga_buffer에 저장하고자 한다.
    • 이때 우리는 unsafe 블록을 사용하여야 하는데, rust에서는 raw pointer를 사용하는 것을 막기 때문이다.(이는 rust compiler가 우리가 사용하는 raw pointer의 유효성을 검증할 능력이 없기 때문이다.)
    • unsafe는 결국 프로그래머가 해당 코드가 안전함을 보장해야만 하기 떄문에, 결코 좋은 방법이 아니므로 남용해서는 안된다.
  • vga_buffer에 HELLO의 byte들을 할당함을 통해서 이를 완성한다.

Run Kernel

Make bootable disk image

  • 커널을 실행시키기 위해서는 먼저, 커널을 부트로더와 연결해야한다.

    • 우리는 부트로더를 직접 작성하지 않고, bootloader라는 도구를 사용할 것이다.
    • cargo add bootloader를 통해서 bootloader를 추가해주자.
    • 또는 Cargo.toml에 다음과 같이 추가해주면 된다.
    # Cargo.toml 에 들어갈 내용

[dependencies]
bootloader = "0.9.23"

  • 또, 우리의 커널을 부트로더가 인식할 수 있는 형태로 변환해야한다.

    • 이를 위해서는 커널을 디스크 이미지로 변환해야한다.
    • 이를 위해서는 bootimage 도구를 사용할 것이다.
      • cargo install bootimage를 통해서 설치할 수 있다.
      • 또한, bootimage를 실행시키기 위해서는 llvm-tools-preview가 필요하기 때문에, rustup component add llvm-tools-preview을 통해서 설치해준다.

  • 여기까지 완료되었다면, cargo bootimage를 통해서 커널을 디스크 이미지로 변환할 수 있다.

Run in QEMU

  • qemu-system-x86_64 -drive format=raw, file=target/x86-64/debug/bootimage-rust_os.bin으로 실행하거나

  • cargo run setting을 통해서 해결한다.

# .cargo/config.toml 에 들어갈 내용

[target.'cfg(target_os = "none")']
runner = "bootimage runner"

References

profile
Layfort
물리와 컴퓨터
이전 포스트

Rust OS 개발일지1

다음 포스트

ARM 공부

0개의 댓글