Maestro: Kernel dựa trên Rust nhằm tương thích với Linux

 (blog.lenot.re)
3 điểm bởi GN⁺ 2024-01-04 | 1 bình luận | Chia sẻ qua WhatsApp
  • Maestro là một dự án nhằm xây dựng lại từ đầu một hệ điều hành họ Unix nhẹ bằng Rust, nhưng vẫn tương thích với Linux đủ để dùng hằng ngày
  • Bắt đầu từ năm 2018 như một dự án ở trường và ban đầu được triển khai bằng ngôn ngữ C, nhưng đã chuyển sang Rust vì các vấn đề quản lý codebase và yêu cầu về an toàn trong phát triển kernel
  • Hiện đây là kernel monolithic cho x86 32-bit; 135 trong số 437 system call của Linux đã được triển khai ở một mức độ nhất định, tương đương khoảng 31%
  • Dự án cũng đang phát triển hệ thống boot kiêm trình quản lý daemon Solfège, các tiện ích hệ thống và trình quản lý gói blimp; musl, bash và một số GNU coreutils cũng đã chạy được
  • Dự án vẫn ở giai đoạn rất sớm và chưa ổn định; việc kiểm thử chủ yếu diễn ra trên QEMU, VMWare và VirtualBox, nên tốt nhất không nên cài lên máy có dữ liệu quan trọng

Mục tiêu và điểm khởi đầu của Maestro

  • Maestro là một hệ điều hành họ Unix được viết từ đầu bằng Rust
  • Mục tiêu là tạo ra một hệ thống nhẹ và đủ tương thích với Linux để có thể dùng hằng ngày
  • Dự án được khởi xướng nhằm tạo ra một môi trường cho phép trực tiếp hiểu hệ thống từ A đến Z và tùy biến theo cách mong muốn

Vì sao chuyển từ C sang Rust

  • Commit đầu tiên được tạo vào 03:18 ngày 22 tháng 12 năm 2018, và dự án khởi đầu như một bài tập ở trường
  • Phần triển khai ban đầu được thực hiện bằng ngôn ngữ C trong khoảng một năm rưỡi, nhưng việc giữ codebase sạch sẽ trở nên khó khăn
  • Những lợi ích nhận được khi bắt đầu lại bằng Rust
    • Có thể thiết kế lại dự án từ đầu dựa trên những gì đã học được từ các sai lầm trước đó
    • Có thể thử những hướng mới hơn thay vì chỉ viết lại một kernel giống Linux bằng C
    • Nhờ hệ thống kiểu của Rust, một phần trách nhiệm về an toàn bộ nhớ có thể được giao cho trình biên dịch thay vì lập trình viên

Những điểm Rust có lợi trong phát triển kernel

  • Debug trong phát triển kernel khó hơn nhiều so với ứng dụng thông thường
    • Khó tìm tài liệu, và bản thân triển khai BIOS có thể có lỗi
    • Khi boot, kernel có quyền truy cập toàn bộ bộ nhớ nên có thể ghi vào những vị trí sai, chẳng hạn như chính mã của nó
    • Không thể dùng các công cụ như valgrind để theo dõi rò rỉ bộ nhớ
    • gdb có thể dùng cùng QEMU hoặc VMWare, nhưng hành vi của kernel có thể khác nhau tùy emulator hoặc máy ảo
    • Cũng có môi trường không hỗ trợ gdb như VirtualBox; hỗ trợ gdb của QEMU và VMWare cũng thiếu một số tính năng, và đôi khi gdb bị crash
  • Để giảm các vấn đề như vậy, một ngôn ngữ an toàn bộ nhớ cũng có lợi trong phát triển kernel
  • Rust đã giúp đưa nhiều cơ chế an toàn vào kernel và được đánh giá là quyết định tốt nhất của dự án

Tình trạng triển khai hiện tại

  • Maestro hiện là kernel monolithic và chỉ hỗ trợ kiến trúc x86 32-bit
  • Tình trạng triển khai tại thời điểm viết bài
    • 135 trong số 437 system call của Linux đã được triển khai ở một mức độ nhất định
    • Tỷ lệ triển khai system call: {p:31}
    • Tính trên toàn bộ repository, có 615 file và 48.800 dòng mã
    • Số dòng được tính bằng lệnh cloc
  • Các thành phần OS ngoài kernel
    • Solfège: hệ thống boot kiêm trình quản lý daemon, phần nào tương tự systemd nhưng nhẹ hơn
    • maestro-utils: bộ lệnh tiện ích hệ thống
    • blimp: trình quản lý gói
    • Các thành phần khác được công khai trên GitHub
  • Phần mềm bên thứ ba đã được xác nhận hoạt động
    • Thư viện chuẩn C musl

    • bash

      • Một số lệnh GNU coreutils như ls, cat, mkdir, rm, rmdir, uname, whoami
      • Vì neofetch gốc không biết Maestro, cần dùng phiên bản neofetch đã được patch

Cách tự kiểm thử và các hạn chế

  • OS vẫn ở giai đoạn rất sớm và rất không ổn định
  • Không khuyến nghị cài đặt trên máy có dữ liệu quan trọng
  • Cho đến nay, dự án chủ yếu được kiểm thử trên QEMU, VMWare và VirtualBox
  • Có hai cách cài đặt
  • ISO bao gồm trình cài đặt OS và có thể chạy trên QEMU, VMWare, VirtualBox, v.v.
  • Cần đủ RAM để chạy ISO, và 1GB là đủ
    • Vì các gói cần cài đặt được lưu trong RAM của initramfs, không phải trên đĩa
    • Hiện OS chưa thể trực tiếp đọc USB stick hoặc CD-ROM, nên phải phụ thuộc vào bootloader

Các chủ đề sẽ được đề cập trong bài viết

  • Mục tiêu không phải là viết hướng dẫn tạo OS
  • Với tài liệu cơ bản về phát triển OS, nên tham khảo osdev.org và blog của Philipp Oppermann
  • Về sau, bài viết dự kiến đề cập các chủ đề nâng cao hơn, quá trình giải quyết vấn đề và cách máy tính, hệ điều hành, Internet vận hành bên trong

Hướng phát triển sắp tới

  • Ưu tiên là dọn dẹp codebase và tối ưu hiệu năng
  • Vì khởi đầu là dự án ở trường, có những phần đã chọn đường tắt để kịp tiến độ, và cần trả bớt nợ kỹ thuật đã tích lũy
  • Một số rò rỉ bộ nhớ cũng cần được sửa, và tối ưu hiệu năng có thể trở thành chủ đề bài viết
  • Mục tiêu lớn tiếp theo là làm cho trình quản lý gói hoạt động hoàn chỉnh trên OS
    • Cần hỗ trợ mạng, hiện đang được phát triển
    • Cần hỗ trợ thư viện chia sẻ
    • Thư viện chia sẻ đòi hỏi ánh xạ trực tiếp file vào bộ nhớ, nhưng hiện triển khai system call mmap của kernel chưa hỗ trợ việc này
  • Sau đó, có thể cài đặt và kiểm thử dễ dàng hơn các chương trình như gcc/g++, clang, rustc, make, Git, Vim
  • Mục tiêu cuối cùng là có quy trình phát triển kernel ngay trên Maestro

Quy trình phát triển để nâng độ hoàn thiện của kernel

  • Việc phát triển diễn ra bằng cách chạy chương trình trên kernel; nếu không hoạt động thì tìm system call gây ra vấn đề rồi triển khai hoặc sửa nó
    • Chạy chương trình trên kernel
    • Nếu không hoạt động, xem đầu ra system call để tìm system call đầu tiên gây vấn đề
    • Nếu system call đó chưa được triển khai hoặc có lỗi, triển khai hoặc sửa nó
    • Chạy lại chương trình
  • Càng nhiều chương trình hoạt động đúng trên kernel, kernel càng ổn định và hoàn thiện hơn

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-04
Ý kiến trên Hacker News

  • Cảm ơn mọi người rất nhiều vì đã ủng hộ; điều đó có ý nghĩa lớn vì tôi đã bỏ rất nhiều công sức vào dự án này
    Có vẻ website hiện khá chậm hoặc đã sập, do lượng traffic lớn hơn dự kiến và cũng nghi ngờ có tấn công DoS
    Hiện tôi đang ở chỗ làm nên khó tập trung xử lý ngay, nhưng khi về nhà tôi sẽ cố sửa để nó hoạt động tốt hơn

    • Có vẻ là DoS do chính hiệu ứng Slashdot của HN gây ra
    • Dự án rất hay, và việc đã chạy được bash ở đây trông như một cột mốc lớn
      Năm 2010, khi Rust còn chưa có, ngay sau khi tốt nghiệp đại học tôi từng nghịch một chút với một hệ điều hành sở thích kiểu Unix viết bằng C, và nó thật sự rất thú vị
      Tôi ghen tị vì bạn đã có thể dành thời gian để đi được đến mức này
    • Mong bạn thử kiểm tra website trên di động
      Thanh điều hướng chiếm khoảng 33% màn hình và không thể bỏ đi
      Tôi không hiểu vì sao người ta cứ cố định những thứ như vậy để lấy mất không gian đọc quý giá. Nếu muốn thì chỉ mất khoảng 300ms là có thể cuộn lên đầu trang

  • Một dự án nhỏ nhưng tuyệt vời. Thật đáng ngạc nhiên là nó có thể boot được đến mức này dù chưa triển khai nổi một phần ba system call của Linux
    Tuy vậy, những phần còn thiếu nhiều khả năng là các phần phức tạp hơn. Ví dụ tầng TTY hiện trông còn khá cơ bản, và để làm cho đúng có lẽ sẽ tốn nhiều công sức
    Vì thế tôi khó kỳ vọng Maestro sẽ chạy được ứng dụng Linux trong vòng 3 năm tới. Ngay cả khi chưa tính đến hàng nghìn driver mà Linux có thì cũng vậy

    • Dự án rất tuyệt, nhưng bản thân tỷ lệ đó thì hoàn toàn không đáng ngạc nhiên
      Các nền tảng trưởng thành tích lũy logic để hỗ trợ nhiều kịch bản, nên phần lớn hệ thống thường không cần đến đa số toàn bộ hệ thống
      Nó giống câu “không ai dùng quá 10% Excel, nhưng 10% mà mỗi người dùng lại khác nhau”
      Chỉ cần triển khai 30% hàm của Excel có lẽ cũng có thể tạo một engine mở được 99% bảng tính trên đời. Nhưng nếu muốn tương thích tài liệu hoàn toàn thì vẫn còn một chặng đường dài
    • Hệ điều hành sở thích của tôi gần giống một kernel tương thích FreeBSD dành cho một VM ngôn ngữ cụ thể. Nó hỗ trợ 61 trong số 424 system call, và đã một thời gian tôi chưa gặp call nào bị thiếu
      Một số system call chỉ được gọi ở những đường đi mã cụ thể, hoặc có thể là call mới chỉ cần khi nhắm đến kernel mới hơn
      System call thì rất nhiều, và trong đó có không ít cái khá khó hiểu. Nếu là một bản thay thế hoàn toàn mở thì cuối cùng chắc phải hỗ trợ hầu hết, nhưng một phần ba là khởi đầu tốt
      [1] Tôi muốn chạy VM trên bare metal hoặc boot vào VM, và ngoài kiểu init=/path/to/the/vm ra thì đây có vẻ là cách ít tốn công nhất để đạt được điều đó. Nhưng cách kia không đem lại thứ tôi thật sự muốn, tức là đặt driver phần cứng và TCP stack bên trong ngôn ngữ VM
    • Có thể chẳng phải sắp tới sẽ có một tập con ứng dụng Linux chạy được sao? Những thứ như proxy, NFS, một số server cơ sở dữ liệu, server HTTP, firewall
      Tôi nghĩ để trở nên hữu ích thì không cần phải chạy được đến Steam, LibreOffice hay Firefox. Nhiều thành phần trong kiến trúc server hoặc microservice thông thường làm việc tương đối đơn giản, và có thể hưởng lợi khá lớn từ một kernel an toàn và đơn giản

  • Cũng có Kerla, một kernel đơn khối viết bằng Rust và từng nhắm đến tương thích Linux ABI. Tuy nhiên có vẻ nó đã ngủ yên vài năm rồi
    [1] https://news.ycombinator.com/item?id=28986229

    • Còn có Redox OS vẫn đang sống: https://www.redox-os.org/
      Nó dùng thiết kế microkernel, và có lẽ trưởng thành hơn một chút. Dùng giấy phép MIT nên có vẻ cũng có khả năng chia sẻ mã

  • Nếu muốn xem “chỉ vì nó viết bằng Rust, liệu một hacker giỏi có tìm được gì không” thì thử làm kiểm thử bảo mật/kiểm thử xâm nhập/fuzzing chắc sẽ thú vị

    • Rust không thể chặn mọi thứ. Hơn nữa còn có nhiều mã unsafe
      Tôi chắc chắn 100% rằng fuzzing hoặc kiểm thử xâm nhập sẽ làm lộ ra rất nhiều vấn đề. Chỉ là tôi chưa có thời gian dành cho việc đó

  • Có vẻ giống việc đã từng được thử trong dự án Kerla hiện đã dừng

  • Nghe như một dự án thú vị. Tuy nhiên tôi nghĩ nhược điểm của việc dùng C và khó khăn của phát triển OS phần lớn nằm ở debug
    Khi chuyển sang Rust, một số loại lỗi bộ nhớ hẳn đã biến mất, nhưng việc debug vẫn đau khổ chứ? Hay nó đã giảm so với trước và trở nên chịu được hơn?

    • Rất nhiều vấn đề về bộ nhớ và đồng thời đã biến mất
      Debug vẫn đau khổ, nhưng đỡ hơn trước rất nhiều
      Ví dụ khả năng quên dùng mutex không cao, vì compiler sẽ báo lỗi
      Dĩ nhiên không phải thuốc tiên, các vấn đề như deadlock vẫn còn. Đặc biệt là khi có interrupt xen vào
      Ví dụ nếu đã khóa một mutex rồi xảy ra interrupt, đoạn mã đang giữ mutex đó sẽ dừng cho đến khi interrupt kết thúc. Nhưng nếu mã xử lý interrupt lại cố khóa cùng mutex đó thì sẽ xảy ra deadlock, và type system không thể giúp được vấn đề này
      Cách giải quyết là vô hiệu hóa xử lý interrupt trong khi mutex đang bị khóa, nhưng compiler không thể ép buộc điều đó

  • Hơi lạc đề, nhưng tôi thích Gource mà tác giả dùng trong video đóng góp
    Trước đây tôi chưa từng thấy nó, nhưng vài năm trước từng có ý tưởng làm một thứ tương tự. Quả là không có ý tưởng nào hoàn toàn mới

  • Đặc biệt nếu vì mục đích học tập, tôi thật sự thích việc tự viết kernel. Tôi tò mò bạn đã dùng tài liệu nào để hiểu kernel và OS nói chung

  • Thật bất ngờ là chưa ai nhắc đến Theseus OS. Đó là một OS đang được phát triển, viết từ đầu bằng Rust, và tận dụng bảo đảm an toàn bộ nhớ của compiler Rust để tự động cung cấp nhiều thứ mà với OS truyền thống sẽ phải nối ghép rất cẩn thận
    Ví dụ nó vẫn an toàn dù dùng một mức đặc quyền duy nhất và cấu trúc một không gian địa chỉ duy nhất. Mọi phần của OS đều có thể hot-plug
    Nhược điểm là toàn bộ mã native đều phải là Rust, nhưng năm ngoái một WASM runtime đã được triển khai. Thread liên quan từ 3 năm trước:
    https://news.ycombinator.com/item?id=25741729

  • Tôi không ngờ lại có người đủ điên để gánh dự án ft_penguin. Tôi vẫn không chắc có đúng tên đó không, nhưng nói thật là làm rất tốt
    Khi còn ở trường 7 năm trước, tôi từng nghĩ đây là một trong những dự án có phần thưởng tệ nhất so với thời gian cần bỏ ra
    Tôi tò mò ban đầu bạn có bắt đầu cùng một người bạn không, và trước khi viết lại bằng Rust thì nó như thế nào. Đồng thời cũng tò mò bạn có làm các dự án khác không
    Nhìn mã làm tôi nhớ lại cảm giác thú vị, và giờ tôi muốn bỏ công việc DevOps để quay lại làm embedded hoặc những công việc low-level khác mà ban đầu tôi định làm