Munal OS - Hệ điều hành thử nghiệm đồ họa với cơ chế sandboxing WASM

• Một hệ điều hành thử nghiệm dựa trên giao diện đồ họa, được triển khai hoàn toàn bằng Rust, sử dụng thiết kế unikernel và mô hình bảo mật sandboxing dựa trên WASM
• Kernel, engine WASM và toàn bộ ứng dụng được nhúng trong một tệp nhị phân EFI, mang lại cấu trúc tối giản và giao diện system call độc đáo
• Chạy trên QEMU thông qua driver dựa trên VirtIO, trong đó quản lý input, mạng và GPU được triển khai bằng cơ chế polling không dùng interrupt
• Hỗ trợ cấu trúc vận hành đơn giản hóa và khả năng giám sát tài nguyên theo từng ứng dụng thông qua vòng lặp sự kiện toàn cục và cooperative scheduling
• Cung cấp UI toolkit Uitk riêng và các ứng dụng tích hợp sẵn (trình duyệt web, trình soạn thảo văn bản, terminal Python), đồng thời có thể phát triển ứng dụng WASM bằng nhiều ngôn ngữ

---

Munal OS là gì

• Munal OS là một hệ điều hành thử nghiệm được phát triển hoàn toàn bằng Rust, là dự án được tạo ra để khám phá một thiết kế OS mới bằng cách kết hợp kiến trúc dựa trên unikernel với sandboxing WASM
• Mục tiêu là giảm độ phức tạp, chỉ áp dụng các thành phần thiết yếu để hiện thực một cấu trúc hệ thống tinh gọn bằng các công cụ hiện đại

Tính năng chính

• Hỗ trợ môi trường đồ họa đầy đủ và độ phân giải HD, kèm giao diện chuột và bàn phím
• Chạy ứng dụng theo mô hình sandbox, ngăn ứng dụng người dùng truy cập bộ nhớ kernel
• Tích hợp driver mạng và stack TCP riêng
• Bao gồm UI toolkit (Uitk) có thể tùy biến, hỗ trợ nhiều widget, bố cục linh hoạt và kết xuất văn bản
• Ứng dụng mặc định: trình duyệt web (hỗ trợ DNS, HTTPS, HTML cơ bản), trình soạn thảo văn bản, terminal Python

Kiến trúc

• Cấu trúc dựa trên tệp nhị phân EFI

  • Chạy dưới dạng tệp nhị phân EFI không cần bootloader, với kernel/engine WASM/ứng dụng được nhúng trong một tệp duy nhất
  • UEFI boot services được kết thúc trong thời gian ngắn nhất có thể, không được sử dụng thêm ngoài đồng hồ hệ thống

• Quản lý không gian địa chỉ

  • Không sử dụng không gian địa chỉ ảo, giữ nguyên địa chỉ identity-mapped do UEFI để lại
  • Không thay đổi page table. Việc bảo vệ trực tiếp bộ nhớ kernel được bù đắp bằng sandboxing WASM

• Driver và hỗ trợ phần cứng

  • Thay vì PS/2 hay VGA, hệ thống tự triển khai trực tiếp driver PCI sử dụng đặc tả VirtIO 1.1
    • Cung cấp driver cho bàn phím, chuột, mạng và GPU
  • Không sử dụng interrupt, tất cả driver đều được thiết kế theo cơ chế polling
  • Chưa hỗ trợ chạy trên phần cứng thực ngoài QEMU, cần phát triển thêm trong tương lai

• Vòng lặp sự kiện và lập lịch

  • Không hỗ trợ đa nhân/interrupt, toàn bộ hệ thống chạy tuần tự trong một vòng lặp sự kiện toàn cục duy nhất
    • Mỗi vòng lặp sẽ polling driver mạng/input, chạy UI desktop và ứng dụng, rồi cập nhật framebuffer GPU
  • Dễ phân tích hiệu năng, có thể đo thời gian theo từng chu kỳ vòng lặp
  • Ứng dụng phải tự giải phóng quyền chiếm CPU, các tác vụ dài cần chủ động nhường quyền thực thi
  • Dựa trên cooperative scheduling, đồng thời có thể hỗ trợ buộc dừng ứng dụng lỗi nhờ tính năng fuel limit của engine Wasmi (chưa triển khai)

Cấu trúc thực thi ứng dụng

• Tích hợp [Wasmi WASM engine], cung cấp sandboxing hoàn toàn và tách biệt với kernel khi chạy ứng dụng
• Cung cấp API system call ở cấp kernel, cho phép ứng dụng truy vấn sự kiện chuột/phím, sử dụng TCP socket, xuất ra framebuffer, v.v.
• Kết quả render của ứng dụng được OS compositing rồi hiển thị lên desktop
• Có thể tạo ứng dụng bằng nhiều ngôn ngữ ngoài Rust, miễn là hỗ trợ build sang WASM
• Tương thích WASI ở mức một phần. Không tuân thủ hoàn toàn, chỉ bao gồm mức triển khai tối thiểu để dùng các phụ thuộc bên ngoài quan trọng
• Mỗi ứng dụng có luồng log riêng (tương tự stdout), có thể xem cùng mức sử dụng tài nguyên trong chế độ “audit” của desktop

UI toolkit (uitk)

• Bộ UI kit immediate-mode riêng, được dùng cả trong Munal OS lẫn các ứng dụng WASM
• Cung cấp widget cơ bản (nút bấm, thanh tiến trình, chỉnh sửa văn bản, canvas cuộn) và bộ rasterizer tam giác
• Kiểu dáng thống nhất dựa trên global stylesheet, đồng thời hỗ trợ override cho từng phần tử riêng lẻ
• Hệ thống cache hiệu quả giúp tránh render lại không cần thiết
  • Chia theo từng “tile” của mỗi vùng, với thuật toán phát hiện thay đổi dựa trên quy tắc mutability của Rust

Môi trường build và chạy

• Có thể build và chạy với Rust Nightly 2025-06-01 và QEMU 10.0.0 trở lên

Tài liệu tham khảo chính và credit

• Rust OS tutorial của Philipp Oppermann và tài liệu từ OSDev Wiki
• Sử dụng nhiều dự án mã nguồn mở quan trọng như Wasmi, smoltcp, Rustls, RustPython
• Sử dụng nhiều phông chữ, biểu tượng và tài nguyên hình nền mã nguồn mở

Ý nghĩa và ưu điểm của Munal OS

• Kết hợp cấu trúc tệp nhị phân EFI đơn nhất với sandboxing mang tính đổi mới, gợi mở việc xem xét lại mô hình thiết kế OS truyền thống
• Tối ưu cho môi trường QEMU cùng cấu trúc driver dựa trên polling độc đáo, giảm thiểu phụ thuộc vào phần cứng hệ thống thực
• Tính minh bạch trong quản lý tài nguyên hệ thống, cùng giá trị học tập và thử nghiệm lớn nhờ cấu trúc đơn giản
• Có tiềm năng lớn để mở rộng hệ sinh thái ứng dụng WASM mà không bị ràng buộc bởi ngôn ngữ hay môi trường

[GN⁺]

Ý kiến trên Hacker News

• Thấy thú vị với cấu trúc mỗi vòng lặp sẽ polling mạng và driver đầu vào, vẽ giao diện desktop, chạy một bước cho từng ứng dụng WASM đang hoạt động rồi flush framebuffer của GPU. Tôi đã tìm mã vì muốn biết họ triển khai phần này bằng Wasmi như thế nào liên kết mã GitHub. Muốn lưu ý rằng trong Wasmi mới nhất (v0.45+), khả năng gọi hàm có thể resume đã được mở rộng để có thể yield khi hết fuel liên kết tài liệu Wasmi. Vì đã dùng fuel metering rồi, đây có thể là cách hiệu quả hơn ở bước thực thi. Có thể xem ví dụ áp dụng trong ví dụ Wasmi Wast runner

  • Một lần nữa cảm ơn vì đã tạo ra Wasmi. Tin về tính năng có thể yield khi hết fuel trong Wasmi thật sự rất thú vị. Tôi từng tiếc vì không tìm thấy khả năng này trong tài liệu trước đây; nếu khi đó đã có thì hướng thiết kế app WASM của tôi hẳn đã khác
  • Tôi không phải OP, nhưng vẫn chưa hiểu vì sao tính năng này lại hữu ích. Ý có phải là tạo coroutine bằng hàm, khởi chạy nó, rồi nếu đang chạy mà thất bại do thiếu bộ nhớ thì có thể cấp thêm bộ nhớ và resume lại coroutine không? Nếu vậy thì nó khác gì so với cách cũ? WASM không có try/catch sao? Nếu sau khi thất bại vẫn phải thử lại malloc một cách tường minh thì tôi hơi bối rối vì chưa thấy khác biệt đủ rõ
  • Tôi rất phấn khích khi thấy Wasmi đủ nhanh để chạy ứng dụng GUI. Tôi đang phát triển một app runtime để tạo GUI app có tính di động và khả năng port cao. Tôi chọn wasm để cân bằng giữa hiệu năng và sự đơn giản khi triển khai, và hy vọng có thể dựng runtime gần như từ con số không chỉ với một hoặc vài người. Việc một wasm runtime dựa trên thông dịch nhưng được tối ưu như Wasmi vẫn có thể chạy GUI app trơn tru khiến tôi thấy có rất nhiều tiềm năng

• Có nhắc rằng vì phụ thuộc vào VirtIO nên Munal OS hiện chưa chạy được trên phần cứng thực. Nếu muốn vận hành trên phần cứng thật thì thay vì tự thêm driver trực tiếp, dùng Linux làm bootloader rồi chạy hệ điều hành trong một hypervisor tối giản cũng là một hướng đi thú vị. Cách này giúp giữ được khái niệm “VirtIO là nền tảng”. Chọn WASM cho việc chạy ứng dụng và VirtIO cho nền tảng là một bản sắc khá hay. Nhưng xét về bảo mật thì vẫn cần dùng MMU. Về mặt thiết kế có thể chưa cần tới bộ nhớ ảo đầy đủ, nhưng để dùng các bit bảo vệ thì vẫn phát sinh thêm độ phức tạp như quản lý page table và TLB, làm suy giảm phần nào sự đơn giản

  • Ở lần thử Hackintosh cuối cùng, tôi cũng từng vận hành tương tự bằng cách dùng Linux làm bootloader kiêm hypervisor tối giản, và hiệu quả khá ổn. Nhược điểm là không có sự kiện GPU thực sự, nên bị cố định theo độ phân giải và cấu hình mà Linux quyết định, khiến độ tự do bị hạn chế. Nếu OS này có thể hoạt động như một tệp thực thi UEFI thay vì một OS “thật”, thì có lẽ vẫn có thể xử lý đồ họa chỉ với driver video UEFI; nhưng tôi không chắc có thể thử như vậy trong khi vẫn giữ được các chức năng đúng nghĩa của một OS hay không

• Tôi nghĩ nhược điểm lớn hơn cả chuyện vòng lặp không được chiếm CPU quá lâu và mọi tác vụ dài đều phải yield tường minh là: càng mở nhiều app thì tốc độ xử lý của từng app càng chậm. Tôi hiếm khi mở hơn 10 app, nhưng từng mở tới 30 tab; nếu mỗi cái đều là một process thì chắc chắn sẽ thấy tụt hiệu năng rõ rệt. Nếu phần cứng đủ nhanh thì không sao, nhưng với các tác vụ nặng như render video chẳng hạn, có thể cảm nhận khác biệt rất lớn như từ 1 giây thành 30 giây. Dù vậy, chỉ riêng việc hiện thực cả OS theo cách này đã là một thử nghiệm cực kỳ thông minh, ấn tượng và đầy hứng khởi

  • App sẽ không nhất thiết phải chậm đi, miễn là chúng hoàn thành việc cần làm đúng hạn. Chạy xong rồi chờ frame kế tiếp là được. Chỉ khi thiếu tài nguyên đến mức thời gian chờ giảm xuống 0 hoặc âm thì toàn hệ thống mới chậm lại; cách này kém thanh lịch hơn một scheduler công bằng phức tạp. Mỗi chương trình sẽ tự yield một cách tường minh khi đã sẵn sàng cho frame, nên app không có gì để làm sẽ gần như không tốn thời gian

• Ngoài cooperative scheduling, việc phòng thủ trước tấn công Spectre cũng có vẻ khó, và tôi cũng nghi ngờ liệu có đạt được hiệu quả nếu không có bộ nhớ ảo hay không. Ví dụ khi xử lý memory.grow trong WASM, nếu vướng vào bộ nhớ của app khác thì có thể phát sinh tình huống phải memmove toàn bộ; không rõ điều đó có thực sự khả thi không. Dù vậy đây vẫn là một dự án cực kỳ ấn tượng

  • Nếu Spectre là một vector tấn công thì tôi muốn hỏi chính xác threat model được giả định ở đây là gì. Trong cấu trúc hiện tại, mọi app đều được biên dịch trực tiếp vào kernel và trình duyệt web cũng không chạy JavaScript, nên có vẻ không hề có đường nào để mã không đáng tin cậy đi vào
  • Mong được giải thích chi tiết hơn

• Tôi tò mò khi wasm component trở thành hiện thực thì những thử nghiệm kiểu này sẽ thay đổi ra sao. Tôi đánh giá cao thiết kế unikernel, và cũng ấn tượng vì Munal OS có khá nhiều chức năng. Tôi hy vọng wasm sẽ được dùng không chỉ cho một ứng dụng đơn khổng lồ mà còn để host nhiều process nhỏ và các môi trường con. Với wasi preview3, khả năng đồng tồn tại giữa đồng bộ và bất đồng bộ có lẽ sẽ sớm mở ra, và khi đó wasm sẽ có gần như đầy đủ các thành phần của một runtime đa dụng. Điều vẫn đáng tiếc là thực tế bridge host object hiện vẫn quá lệch về phía JS, nhưng tôi muốn thấy lời hứa của wasm component — tiêu chuẩn, nhẹ, sandbox, phối hợp đa ngôn ngữ — được thể hiện trong đời thực như một năng lực runtime thực sự chứ không chỉ là một định dạng phân phối. Có thể tham khảo thêm talk này What is a Component (and Why)

  • Khi nói về chủ đề này, có phải bạn định nhắc đến video này không liên kết YouTube
  • Tôi đã bắt đầu làm một ứng dụng Rust hỗ trợ SDL3 và nhúng V8 để có thể script giới thiệu trên blog. Nhưng điều tôi đang nghiêm túc cân nhắc là fork nó rồi nhúng wasmtime hoặc wasmi để có thể script bằng bất kỳ ngôn ngữ nào. Thậm chí có thể nhúng cả compiler để chỉ cần đưa file vào là script chạy ngay. Lý do là wasmtime và wasmi nhanh hơn các scripting engine khác dữ liệu so sánh. Tuy vậy điểm bất tiện là phải thiết lập toàn bộ môi trường mã nguồn, nên lợi thế gia nhập như một ngôn ngữ script bị yếu đi. Dù sao ý tưởng này quá ngầu nên tôi rất muốn thử ít nhất một lần

• Tôi từng xem talk “The Birth and Death of Javascript” tại Pycon 2014, trong đó có đoạn giới thiệu tương lai triển khai sandbox OS bằng asm.js (tiền thân của wasm hiện nay); ý tưởng đó trông rất giống với cốt lõi thiết kế của dự án này nên tôi tò mò không biết nó có ảnh hưởng gì không liên kết talk

  • Tôi nghĩ có lẽ nó chịu ảnh hưởng từ Midori, hệ điều hành nghiên cứu của Microsoft, nhiều hơn giới thiệu Midori

• Tôi ngạc nhiên khi thấy OS này còn tích hợp cả trình duyệt web riêng mã nguồn trình duyệt web. Trong video demo cũng có thể thấy nó render Hacker News

  • Trước khi các trình duyệt web bị dồn thêm JS, CSS và đủ loại tính năng, những trình duyệt nhỏ như thế này vẫn có thể xem web với mức phụ thuộc tối thiểu; nhưng bây giờ thì lại khó có thể xem được phần lớn web một cách có ý nghĩa, điều này khá đáng tiếc. Tôi nghĩ cần tách bạch rõ hơn giữa web thiên về nội dung và web thiên về ứng dụng. Web nội dung chỉ cần một HTTP client rất đơn giản cùng HTML parser, còn web app thì giống OS này, chỉ cần nền tảng wasm cộng với một số ít hardware API là đủ. Tuy nhiên nhất định phải có hỗ trợ UDP

• Vừa thấy kinh ngạc vừa tự hỏi liệu cấu trúc như vậy có thể là tương lai của OS hay không. Ngay cả readme cũng rất thú vị. Tôi tò mò vì sao lại chọn wasmi thay vì wasmtime. Tôi cũng muốn tự thử OS này trên VM và còn có tham vọng port thư viện GUI của mình sang Munal

  • Tôi chia sẻ kinh nghiệm rằng build wasmtime ở chế độ no_std quá rắc rối, nên cuối cùng đã chọn wasmi
  • Thêm một câu đùa rằng khi nói về tương lai của cấu trúc OS hiện đại thì SPECTRE và MELTDOWN cũng chen vào
  • Có nhắc rằng vì dùng ảo hóa để cách ly app nên trên Qubes OS người ta đã phần nào trải nghiệm tương lai tương tự rồi. Ở đó việc cách ly app được thực hiện rất chắc chắn

• Từ thời Xerox PARC, các nỗ lực “bytecode hóa userspace” đã lặp đi lặp lại, và theo tôi những ví dụ thực sự thành công trên thị trường chỉ có IBM i, ChromeOS và Android. Dù vậy dự án này rất ngầu và tôi mong nó thành công

  • Có cảm giác việc bạn lặp lại chuyện về các VM bytecode đời cũ trong mọi thread liên quan đến WebAssembly giờ đã thành một mô thức. Lúc nào cũng là cùng một giọng điệu đánh giá lặp lại, trong khi ở cộng đồng phát triển thì việc có nhiều thử nghiệm, nhiều lần vấp ngã và cách tiếp cận mới là điều tất yếu. Tôi muốn nghe các ý kiến cụ thể hơn thay vì chỉ là nhận diện mô thức ở mức cơ bản
  • Chính vì khái niệm này có ưu điểm quá rõ ràng nên những thử nghiệm mới sẽ còn tiếp tục lặp lại cho tới khi nó thật sự đứng vững như một tiêu chuẩn. wasm khác hẳn JVM và các thứ tương tự ở chỗ nó thực sự nhắm tới mục tiêu đó
  • ChromeOS về cơ bản chỉ là một trình duyệt nên việc dùng V8 cũng chỉ là ngẫu nhiên, còn Android thì tôi nghĩ dùng cái gì nó cũng vẫn thành công. Lý do hai OS đó thành công không phải công nghệ mà là giá cả

• Thiết kế của một client OS như vậy thật đáng kinh ngạc. Tôi nghĩ kiểu cấu trúc này cũng có thể thực dụng ngay trên server. Nếu làm kernel thật nhỏ và chỉ giữ lại một app duy nhất đang chạy thì có thể giảm bớt các ranh giới bảo mật không cần thiết. Ví dụ một key/value store sẽ rất hợp với kiểu cấu trúc này. Điều tôi tò mò là với mô hình IO như vậy thì hiệu năng mạng có tốt không, và khi host WASM có thể áp dụng kỹ thuật đặc biệt nào để giảm các bản sao bộ nhớ không cần thiết hay không