OS with Rust, OS 개발기 - 2. 운영체제로 거듭나다(Reborn OS)

OS with Rust

1. 운영체제를 넘어서(Beyond OS)
2. 운영체제로 거듭나다(Reborn OS)

 

이번 시간에는 x86 아키텍처에서 최소한의 기능으로 동작하는 64비트 Rust 커널을 만들어 볼 것입니다. 지난 시간에 우리는 Rust로 Free Standing 실행 파일을 만들었습니다. 이번에는 이 바이너리를 실제로 부팅 가능한 디스크 이미지로 만들고, 화면에 문자열 출력까지 해봅시다.

 

 

어엿한 운영체제 

 

본격적으로 우리의 새로운 무대를 구성해봅시다. 지난 시간의 Free Standing 실행 파일을 어엿한 운영체제라고 부를 수 있는 디스크 이미로 만들어 나갈 것입니다.

 

먼저, rustup override set nightly 명령어를 통해 현재 디렉토리에서 항상 nightly 버전의 Rust를 사용하도록 설정합니다. rustc --version 명령어를 통해 nightly 버전이 잘 설치되었는지 확인해보세요. ex) rustc 1.72.0-nightly

 

nightly 버전의 Rust는 Rust의 실험적인 기능들을 사용할 수 있게 해줍니다. 물론, 문자 그대로 실험적인 기능들이기에 미래의 Rust 버전에서 삭제될 가능성이 존재합니다. 그래서 우리는 이 실험적인 기능들의 사용을 최소한으로 줄일 것입니다.

 

이제 Rust의 컴파일 목표를 정의합시다. 지난 시간에 우리는 target triple의 한 가지 예시로  thumbv7em-none-eabihf를 목표로 빌드해보았습니다. 하지만 우리의 목표는 완전히 새로운 컴파일 목표 환경(운영체제에 종속되지 않는)이기에 이번 시간에는 직접 컴파일 목표를 정의해볼 것입니다.

 

일단 x86_64-new_stage.json 파일을 생성합니다.

// x86_64-new_stage.json

{
    "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이 사용하는 특정 하드웨어와 운영체제에 대한 정보를 제공합니다. 여기서 "x86_64"는 CPU 아키텍처를, "unknown"은 벤더(vendor)를, "none"은 운영체제를 나타냅니다. 이 값이 "x86_64-unknown-none"이므로, 컴파일러는 64비트 x86 프로세서를 위한 코드를 생성하며, 벤더 정보가 없고, 특정 운영체제 없이 실행될 수 있도록 코드를 생성합니다.


data-layout: 이 설정은 LLVM이 데이터를 메모리에 배치하는 방식을 제어합니다. 여기서 각 서브필드는 특정 데이터 타입에 대한 정보를 제공합니다. 예를 들어, "e"는 리틀 엔디언을 나타내며, "i64:64"는 64비트 정수가 64비트 경계에 맞춰진다는 것을 나타냅니다. "f80:128"는 80비트 부동소수점 수가 128비트 경계에 맞춰진다는 것을 나타냅니다. 이외에도 많은 데이터 타입에 대한 정보를 제공합니다.


arch: 이 설정은 타겟 아키텍처를 나타냅니다. 여기서는 "x86_64"가 사용되었습니다.


target-endian: 이 설정은 타겟 시스템의 엔디언을 지정합니다. 여기서는 "little"이 사용되었으므로, 리틀 엔디언을 사용하는 시스템을 대상으로 합니다.


target-pointer-width: 이 설정은 타겟 시스템에서의 포인터의 크기를 비트 단위로 지정합니다. 여기서는 "64"가 사용되었으므로, 64비트 포인터를 사용하는 시스템을 대상으로 합니다.


target-c-int-width: 이 설정은 타겟 시스템에서 C 언어의 int 데이터 타입의 크기를 비트 단위로 지정합니다. 여기서는 "32"가 사용되었으므로, 32비트 int를 사용하는 시스템을 대상으로 합니다.


os: 이 설정은 타겟 시스템의 운영체제를 지정합니다. 여기서는 "none"이 사용되었으므로, 특정 운영체제 없이 실행될 수 있는 코드를 생성합니다.


executables: 이 설정은 Rust 프로그램이 실행 파일을 생성할 수 있는지 여부를 지정합니다. 여기서는 'true'로 지정되어 Rust 컴파일러가 주어진 소스 코드를 기계어 코드로 컴파일하고, 이를 실행 가능한 형태로 패키징하는 데 필요한 추가 작업을 수행합니다.


linker-flavor: 이 설정은 링커의 유형을 지정합니다. 링커는 여러 개의 오브젝트 파일이나 라이브러리를 결합하여 하나의 실행 파일을 생성하는 도구입니다. "ld.lld"는 LLVM 프로젝트의 링커인 LLD를 사용하겠다는 의미입니다.


linker: 이 설정은 사용할 링커의 이름을 지정합니다. 여기서는 "rust-lld"가 사용되었는데, 이는 Rust에 내장된 LLD 링커를 사용하겠다는 의미입니다.


panic-strategy: 이 설정은 Rust 프로그램이 패닉 상태(즉, 예상치 못한 에러 발생 시)에 도달했을 때 어떻게 동작해야 할지를 지정합니다. "abort"는 패닉이 발생하면 프로그램을 즉시 종료하겠다는 의미입니다. 지난 시간에 Cargo.toml 파일에 panic = "abort" 설정을 추가하는 것과 비슷한 효과이기에, Cargo.toml에서는 해당 설정을 지우셔도 괜찮습니다.


disable-redzone: 이 설정은 커널 스택에 대한 "red zone" 최적화를 비활성화할지 여부를 지정합니다. "red zone"은 함수 호출에서 발생하는 스택 프레임 간의 간격을 더 효율적으로 관리하기 위한 것입니다. 하지만, 커널 코드에서는 인터럽트 핸들러가 스택을 안전하게 사용할 수 있도록 이 최적화를 비활성화하는 것이 필요합니다.


features: 이 설정은 타겟 아키텍처가 사용할 수 있는 특정 하드웨어 기능을 활성화하거나 비활성화하는 데 사용됩니다. 이 설정은 LLVM에서 사용하며, 아키텍처가 지원하는 특정 명령어 집합을 활성화하거나 비활성화합니다.

"-mmx": 이 설정은 MMX(Multi-Media Extensions) 기능을 비활성화합니다. MMX는 Intel에서 개발한 SIMD(Single Instruction, Multiple Data) 명령어 집합입니다. SIMD는 한 번의 명령으로 여러 데이터에 동시에 연산을 수행할 수 있게 해주는 기술로, 그래픽, 통신, 비디오 등 병렬 연산이 필요한 작업에서 주로 사용됩니다. "-mmx"는 이 MMX 기능을 비활성화함을 의미합니다.

"-sse": SSE(Streaming SIMD Extensions)도 마찬가지로 Intel에서 개발한 SIMD 명령어 집합입니다. SSE는 MMX를 개선하고 확장한 것으로, 부동 소수점 연산에 특화되어 있습니다. "-sse"는 이 SSE 기능을 비활성화함을 의미합니다.

"+soft-float": 이 설정은 소프트웨어 기반의 부동소수점 연산을 활성화합니다. 일반적으로, CPU의 하드웨어 부동소수점 유닛(FPU)을 사용하여 부동소수점 연산을 수행하는 것이 빠르지만, 모든 시스템이 이를 지원하지 않습니다. 그런 시스템에서는 소프트웨어로 이러한 연산을 에뮬레이션해야 하며, 이를 가능하게 하는 것이 "soft-float" 설정입니다.

 

이제 지난 시간에 만든 크레이트를 --target 인자를 통해 JSON 파일을 전달하여 빌드해봅시다.

 

cargo build --target x86_64-new_stage.json

 

빌드하게되면 core 크레이트를 찾지 못한다고 나올 것입니다.

error[E0463]: can't find crate for `core`

 

이는 Rust 컴파일러가 core 라이브러리를 찾지 못하였다는 뜻입니다. Rust의 기본 타입들을 담고 있는 core 라이브러리는 no_std 크레이트에 자동으로 연결됩니다. 그런데 이 라이브러리는 미리 컴파일된 형태로 제공되어, 우리의 커스텀 환경에서 바로 사용할 수 없습니다. 따라서 우리가 지정한 커스텀 환경에 맞게 core 라이브러리를 다시 빌드해야 합니다.

 

이런 상황에서 도움이 되는 것이 바로 cargo의 build-std 기능입니다. 이 기능은 Rust의 표준 라이브러리 크레이트를 재컴파일하는 데 사용합니다. 하지만 이 기능은 아직 개발 중인 상태로, "unstable" 기능으로 분류되어 nightly 버전의 Rust 컴파일러에서만 사용 가능합니다.

 

이 기능을 사용하려면, .cargo/config.toml 파일에 다음과 같은 설정을 추가해야 합니다.

# .cargo/config.toml

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

 

위 설정은 core와 compiler_builtins 라이브러리를 재컴파일하도록 지시합니다. core가 이용하는 compiler_builtins도 함께 새롭게 컴파일해야 합니다. 이 라이브러리의 소스 코드를 얻기 위해 rustup component add rust-src 명령을 실행합니다.

 

이후 , cargo build --target x86_64-new_stage.json 명령어를 통해 다시 빌드하게되면 성공적으로 컴파일되는 것을 확인하실 수 있습니다.

 

 

이제 cargo build가 우리의 커스텀 컴파일 대상 환경에 맞춰 core, rustc-std-workspace-core, 그리고 compiler_builtins 라이브러리를 재컴파일하고 있습니다.

 

 

성공적으로 빌드는 되었지만, 아직 문제는 남아있습니다. Rust 컴파일러는 특정 내장 함수들이 모든 시스템에서 제공된다고 가정합니다. 이러한 함수들은 주로 메모리 관련 기능을 가진 함수들입니다.

메모리 관련 함수들로는 memset(메모리 블럭 전체에 특정 값 저장하기), memcpy (한 메모리 블럭의 데이터를 다른 메모리 블럭에 복사하기), memcmp (두 메모리 블럭의 데이터 비교하기) 등이 있습니다.

이런 함수들은 일반적으로 C 라이브러리가 제공합니다. 그러나 우리가 직접 운영체제를 만드는 상황에서는 C 라이브러리를 사용할 수 없습니다. 이 때문에 이런 함수들을 직접 구현하거나, 이미 구현된 함수를 사용해야 합니다.

다행히, Rust는 이런 함수들을 compiler_builtins라는 라이브러리에 구현해놓았습니다. 이 라이브러리는 기본적으로 C 라이브러리와 충돌을 방지하기 위해 해당 함수들을 비활성화 상태로 두었지만, 필요에 따라 활성화시켜 사용할 수 있습니다. 이를 위해 build-std-features 플래그에 "compiler-builtins-mem"을 추가하면 됩니다.

 

# .cargo/config.toml

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

[build]
target = "x86_64-new_stage.json"

 

.cargo/config.toml 파일에 설정을 추가해줍시다. 추가적으로 아래에 [build] 설정을 통해 명령어에 --target 인자를 추가하지 않아도 됩니다. 단순히 cargo build 명령어만으로 편하게 빌드할 수 있도록 설정합시다.

 

이제 모든 초기 세팅이 끝났습니다. 이렇게 설정한 뒤 커널을 빌드하면, 컴파일러는 커널 코드를 문제 없이 컴파일할 수 있게 됩니다. 이제는 컴파일하는데 지장없이 커널의 기능을 확장해나갈 수 있습니다.

 

이번에는 화면에 문자열까지 출력해봅시다. 화면에 문자열을 출력하기 위해선 VGA 텍스트 버퍼라는 특별한 메모리 공간을 사용할 수 있습니다. 이 메모리 공간은 VGA 하드웨어에 직접 매핑되며, 화면에 보여지는 내용이 여기에 저장됩니다. 주로, 이 텍스트 버퍼는 25행 80열 (각 행마다 80개의 문자)로 이루어져 있습니다. 이때 각각의 문자는 ASCII 문자이며, 각 문자에는 전경색과 배경색이 지정되어 화면에 표시됩니다.

VGA 텍스트 버퍼의 구조는 다음에 자세히 설명하겠지만, 문자열을 출력하는데 있어서는 단순히 버퍼의 시작 주소를 알고, 각 문자에 필요한 ASCII 문자와 색상 코드가 필요하다는 것만 알면 됩니다.

 

// main.rs

static GREETING: &[u8] = b"The curtain rises.";

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

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

    loop {}
}

 

위와 같이 main.rs 파일의 _start() 함수를 수정해줍시다. 위 예제는 정수 0xb8000을 raw 포인터로 변환합니다. 그 후에, 정적 바이트 문자열 GREETING의 각 바이트를 읽고, 각 바이트의 인덱스 값을 얻습니다. VGA 버퍼에 문자열의 각 바이트와 색상 코드를 저장합니다(0xb는 연한 청색을 나타내는 색상 코드입니다).

메모리에 쓰는 코드는 unsafe 블록 내부에 위치합니다. 이는 Rust 컴파일러가 원시 포인터의 유효성을 검증할 수 없기 때문입니다. unsafe 블록 내부에 코드를 작성함으로써, 우리는 컴파일러에게 이 메모리 쓰기 작업이 안전하다고 보장합니다. 그러나 이런 유형의 Rust 코드를 작성하는 것은 바람직하지 않습니다! raw pointer를 사용하면 메모리 버퍼를 넘어서는 메모리 주소에 쓰는 실수를 쉽게 할 수 있습니다.

따라서 unsafe 블록의 사용을 최소화하고, 이를 위해 Rust에서는 안전한 추상화 계층을 만들어 사용합니다. 예를 들어, 모든 위험한 요소들을 캡슐화한 VGA 버퍼 타입을 만들어 외부 사용자가 메모리 안전성을 위협할 수 없도록 할 수 있습니다. 이렇게 설계하면, 최소한의 unsafe 블록을 사용하면서도 메모리 안전성을 위협하지 않을 것임을 확신할 수 있습니다. 이는 다음 시간에 할 것입니다. 일단은 이 상태로 실행시켜봅시다.

 

 

우리가 만든 커널을 실행해보려면, 먼저 부팅 가능한 디스크 이미지를 생성해야 합니다. 이렇게 하기 위해선, 컴파일된 커널을 부트로더와 연결해야 합니다. 이를 위해, 우리는 Rust의 'bootloader'라는 라이브러리를 활용할 것입니다. 이 라이브러리는 BIOS 부트로더를 간편하게 구현하며, 이를 통해 우리의 커널을 부팅할 수 있습니다.

다음과 같이 Cargo.toml 파일에 'bootloader' 의존성을 추가해줍시다.

[dependencies]
bootloader = "0.9.23"

 

그러나 이것만으로는 부트로더와 커널을 연결해 디스크 이미지를 생성할 수 없습니다. 이 문제를 해결하기 위해, 'bootimage'라는 도구를 사용합니다. 이 도구는 커널과 부트로더를 디스크 이미지로 합쳐주는 역할을 합니다.

 

cargo install bootimage

cargo bootimage

 

위 명령어들을 실행하면 커널이 컴파일되고, 이후 부트로더가 컴파일됩니다. 처음 실행시엔 시간이 걸릴 수 있지만, 이후부터는 빌드 결과가 캐시되어 시간이 크게 단축됩니다. 이 과정이 완료되면, target/x86_64-new_stage/debug 디렉토리에 'bootimage-new_stage.bin'라는 부팅 가능한 디스크 이미지가 생성됩니다. 이 이미지는 가상 머신이나 실제 하드웨어에서 부팅할 수 있습니다.

 

* 동작 원리

부트로더는 커널의 ELF 파일을 읽고 해당 내용을 메모리에 로드합니다. 이후 프로그램의 각 세그먼트를 해당하는 가상 주소 공간으로 매핑하고, 모든 메모리 값을 초기화한 후, 프로그램의 시작 지점(_start 함수)으로 제어를 넘깁니다.

 

 

자 얼마 안 남았습니다. 다음 단계로, QEMU라는 가상 머신에서 우리가 만든 디스크 이미지를 부팅해봅니다.

 

이곳에서 자신의 운영체제에 맞춰 QEMU를 설치해줍시다.

https://www.qemu.org/download/

Download QEMU - QEMU

 

설치가 완료된 후, 환경 변수 설정도 되어있다면 다음과 같은 명령어를 사용하면 됩니다.

qemu-system-x86_64 -drive format=raw,file=target/x86_64-new_stage/debug/bootimage-new_stage.bin

 

 

화면에 “The curtain rises.” 라는 메세지가 출력된 것을 확인하실 수 있습니다.

 

 

이제 마지막으로, cargo run 명령어로 우리의 커널을 컴파일하고 가상 머신에서 바로 실행할 수 있게 해봅시다. cargo 설정에 runner라는 옵션을 추가하도록 하겠습니다.

 

# .cargo/config.toml

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

 

위 설정에서 target.'cfg(target_os = "none")' 부분은 "os" 필드가 "none"으로 설정된 컴파일 타겟에만 적용되는 것을 의미합니다. 즉, 우리의 x86_64-blog_os.json도 해당 범위에 속하게 됩니다. runner 키는 cargo run이 실행될 때 어떤 명령어를 사용할 것인지를 지정합니다. 빌드가 성공적으로 완료된 이후에 runner 키에 지정된 명령어가 실행됩니다. 더욱 자세한 정보를 얻고 싶다면 cargo 공식 문서를 참조하시면 좋습니다.

bootimage runner라는 명령어는 프로젝트의 부트로더 라이브러리를 링크한 후에 QEMU를 실행시키는 역할을 합니다. 따라서 일반적인 실행파일을 실행하는 것처럼 bootimage runner 명령어를 사용하면 됩니다. bootimage 의 사용 방법과 다양한 설정 옵션에 대한 정보는 bootimage 의 Readme 문서를 참조하시면 됩니다.

이제 cargo run 명령어로 우리의 커널을 컴파일하고 가상 머신에서 실행시킬 수 있습니다.

 

수고많으셨습니다. 다음 시간에는 앞서 말한 메모리 안정성을 위한 추상 계층을 더한  VGA 버퍼 타입을 구현해봅시다.

 

 

Thanks for watching, Have a nice day.

 

References

https://os.phil-opp.com/

 

<- 이전으로