windows-drivers-rs - Rust에서 Windows 드라이버 개발을 가능하게 하는 플랫폼

 (github.com/microsoft)
3P by GN⁺ | ★ favorite | 댓글 3개
  • Windows Drivers를 Rust로 개발할 수 있게 하는 Rust crate 모음으로, WDM과 WDF 드라이버 개발 모델 지원을 목표로 함
  • 주요 구성은 WDK 빌드 설정용 wdk-build, WDK API 직접 FFI 바인딩 wdk-sys, 안전하고 관용적인 WDK API 바인딩 wdk, panic handler용 wdk-panic, alloc 지원용 wdk-alloc, wdk-sys 직접 바인딩 사용을 돕는 매크로 모음 wdk-macros임
  • WDM, KMDF, UMDF 드라이버와 Win32 Services 지원을 염두에 두고 만들어졌으며, WDK 22H2 이상에 포함된 모든 WDF 버전 지원을 포함함
  • crates.io에 공개된 crate는 현재 KMDF v1.33만 지원하며, 다른 구성의 바인딩은 windows-drivers-rs를 clone한 뒤 wdk-sys의 build.rs 설정을 수정해 생성 가능함
  • 사용 흐름은 Cargo lib 패키지 생성, wdk-build, wdk, wdk-sys, wdk-alloc, wdk-panic 의존성 추가, cdylib 설정, WDK metadata 설정, build.rs에서 wdk_build::configure_wdk_binary_build() 호출, DriverEntry 추가, cargo make 실행으로 구성됨
    • Kernel Mode crate인 KMDF와 WDM 드라이버는 panic 전략 abort, #![no_std], panic handler 설정이 필요함
    • Rust 표준 라이브러리의 alloc 모듈을 쓰려면 wdk_alloc::WdkAllocator 전역 allocator 설정이 필요함
  • 빌드 요구사항은 bindgen용 libclang, post-build 작업용 cargo-make, 유효한 WDK 환경이며, 권장 방식은 eWDK developer prompt 진입임
  • cargo make는 기본 동작으로 드라이버를 빌드하고 패키징하며, 결과로 서명된 드라이버 패키지와 WDRLocalTestCert.cer 파일이 target/<Cargo profile>/package 또는 target architecture 경로 아래 생성됨
  • cargo make default --target <TARGET TRIPLE>, --release, --features <FEATURES>, +<TOOLCHAIN> 같은 인자 전달을 지원하며, WDK_BUILD_ENABLE_SIGNTOOL_VERIFY=true 설정으로 생성된 .sys와 .cat 파일의 서명 검증 작업 활성화 가능함
  • 새 Cargo 확장 cargo-wdk는 cargo-make를 Rust 드라이버 빌드 권장 도구에서 대체하기 위해 개발 중인 Preview 상태임
  • WDM, KMDF, UMDF 최소 예제는 examples directory에 있으며, 드라이버 생성 예시는 Windows-rust-driver-samples에서 확인 가능함
  • 아직 개발 초기 단계이며 production use에는 아직 권장되지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 기억 못 하는 분들을 위해 말하면, Mark Russinovich는 상사의 자리를 이어받고 차기 MSFT CEO 후보로 거론되기 전, Redmond 엔지니어들이 NT 커널 개발을 배우러 가던 소프트웨어 도구 및 NT 커널 컨설팅 회사를 운영했음
    또 Sony의 DRM 루트킷, Symantec의 루트킷 같은 파일 보호 기능을 찾아냈고, Best Buy가 ERD Commander를 불법 복제한 것도 잡아냈음
    2014년에 LinkedIn을 날려버린 게 지금은 좀 아쉬움. Valley 전체와 Mark가 1촌으로 있던 계정이었는데, 그래도 상대적 무명에는 자유와 기민함이 있음. 얼마나 했고 벌었고 누구를 알았는지 떠드는 게 무의미하다는 Desmond Dekker 레게 노래가 뭐였더라

    • Apple도 비슷한 일을 했던 것 같음. 내부 Apple 문서는 Jonathan Levin의 책에 비하면 별것 아니어서, Apple이 OS 엔지니어용으로 그 책들을 자주 샀다고 함
      그 규모의 회사들이 실제 소스 코드와 엔지니어 접근권이라는 훨씬 유리한 위치에 있으면서도 이런 일을 스스로 잘 못 한다는 게 꽤 흥미로움. 이런 제3자들, 적어도 Levin은 상당 부분 역공학에 의존해야 했음
      https://newosxbook.com
    • 그를 말하면서 Sysinternals를 빼놓을 수는 없음. 매일 업무에 그 도구 모음에 의존함
      전 세계에서 Windows를 쓰는 거의 모든 회사가 최소 하나의 Sysinternals 도구를 쓰는 걸 생각하면, Sysinternals의 영향력은 어쩌면 Azure 자체보다도 컸을 수 있음
    • Sysinternals 도구는 모든 Windows 설치에 기본 포함돼야 함. 내 환경에서는 필수이고, 친구 컴퓨터를 고치거나 디버깅할 때 없으면 정말 아쉬움
      MSFT가 Mark Russinovich와 그 팀을 acquihire한 이유도 그 때문 아니겠나
    • 그는 좋은 프로그래머지만, 그의 책을 읽어보면 좋은 CEO가 될 것 같지는 않음
      첫 책에서 받은 인상은 세상을 극도로 흑백으로 본다는 것이었음

  • 원본 트윗: https://twitter.com/markrussinovich/status/17057307039574058...

  • 멋진 /s지만, 이건 Rust답지 않음:
    pub struct QueueContext {
    buffer: PVOID,
    length: usize,
    timer: wdf::Timer,
    current_request: WDFREQUEST,
    current_status: NTSTATUS,
    spin_lock: wdf::SpinLock,
    }

    • 저것들 대부분은 결국 FFI 정수 타입을 가리킴. Windows 드라이버 API가 그렇게 쓰기 때문임
      Linux 커널에서 Rust 드라이버를 쓸 때도 비슷한 문제가 있고, C와 상호 운용하는 다른 프로젝트도 마찬가지임
      NTSTATUS 같은 타입에는 문서가 상당히 많이 붙어 있음. C나 C++와 달리 Rust에서는 정수 값을 enum 값에 그냥 대입할 수 없음. 래퍼 클래스를 생성해서 매번 캐스팅하게 만들 수도 있겠지만, 그러면 코드 절반이 .into()가 되고 드라이버에 오버헤드도 생길 가능성이 큼
      보기에 buffer용 void* 정도를 제외하면 이런 enum 값들을 설정하거나 바꾸는 게 아니라 읽기만 함. NTSTATUS에는 match {} 블록이면 충분할 것 같음. WDFREQUEST는 핸들이라 같은 타입의 다른 핸들로 바꾸는 것 말고는 할 수 있는 일도 별로 없음
      Timer와 SpinLock은 unsafe 라이브러리 호출을 내부에 감싼 Rust다운 객체로 바뀌어 있음. 그 외에는 상당한 성능 부담 없이 이 코드를 더 Rust답게 만드는 방법이 잘 보이지 않음
    • 저걸 없애려면 전부 다시 작성해야 할 것 같음

  • 더 나은 건 뭔지 아나? C# 같은 메모리 관리 언어로 장치 드라이버를 쓰는 것임

    • Microsoft는 점점 더 많은 코드를 사용자 공간으로 밀어내고 있음. 최신 변화로는 프린터 제조사들이 프린터에 커스텀 기능을 추가할 때 드라이버가 아니라 UWP 프린터 앱을 쓰라고 요구함. 이런 앱은 보통 C# 같은 언어로 작성됨
      커널을 더 쉽게 접근 가능하게 만드는 것보다, 커널 안에서 제조사 코드를 덜 실행하는 편이 최선이라는 Microsoft의 판단에 동의함. C#은 “어떤 버퍼에 접근하고 싶은데 아직 페이지 인되지 않았고, 나는 인터럽트 핸들러 안에 있다” 같은 상황에 적합하지 않아서, 커널에서 가비지 컬렉터를 버그 없이 돌리는 건 거의 불가능해 보임
    • 정말 더 나을지는 모르겠음. 드라이버 개발 경험은 없지만, 장치 드라이버는 동작하는 운영체제의 저수준 핵심 구성 요소라서 가비지 컬렉션이 자기 일정대로 실행을 끊는 방식과는 잘 맞지 않아 보임
    • 드라이버가 가비지 컬렉터를 돌리느라 멈춰서 마우스가 버벅이는 건 원치 않음
    • Microsoft가 이미 시도했지만 처참히 실패했음. 이유를 밝히진 않았던 것 같지만, 2000년대 초반 하드웨어에서는 가비지 컬렉션 때문에 멈춤이 너무 많았을 거라고 봄
    • C++로도 페이지 가능 커널 드라이버 작성 능력을 유지하면서 장치 드라이버를 쓰기는 매우 어려움
      드라이버는 페이지 폴트가 불가능한 시점, 예를 들어 인터럽트 핸들러 중에도 메모리에 접근할 가능성이 있어서 메모리 가용성을 아주 엄격하게 제어해야 함. C# 언어와 런타임은 최소한 이를 명시적으로 다룰 기능을 추가해야 함
답변달기
bungker   [-]

조금 저 평가되는것 같아 덧붙입니다. Russinovich 윈도우 커널과 관련해서 수많은 자료와 툴을 만든 사람입니다. 윈도우 커널 관련 개발자중에( 루트킷을 만든 개발자들 포함)에 Russinovich 의 자료나 문서를 보고 공부하지 않았던 사람은 없을것 같습니다.

답변달기
botplaysdice   [-]

윈도우즈 커널을 Rust로 재작성 중이라는 얘기가 있더니, 드디어 드라이버 SDK가 나오고 있군요. 조만간 20XX년 부터는 Rust로 드라이버를 만들라는 공지가나올듯.

답변달기