Cộng đồng công nghệ đang sôi nổi thảo luận về Asterinas, một kernel tương thích Linux mới được viết bằng Rust và giới thiệu kiến trúc framekernel độc đáo. Trong khi dự án này nhằm kết hợp những khía cạnh tốt nhất của thiết kế monolithic và microkernel, các thành viên cộng đồng đang đặt ra những câu hỏi quan trọng về tính khả thi thực tế và cách tiếp cận kỹ thuật của nó.
Thông số kỹ thuật của Asterinas
- Ngôn ngữ: Rust với kiến trúc framekernel
- Tương thích: Tương thích với Linux ABI
- Giấy phép: Mozilla Public License (MPL) 2.0
- Kiến trúc: Chia thành framework có đặc quyền (unsafe Rust) và các dịch vụ không có đặc quyền (safe Rust)
- Trường hợp sử dụng mục tiêu: Ban đầu tập trung vào Confidential VMs và môi trường ảo hóa
- Lộ trình phát triển: Mục tiêu hỗ trợ các dịch vụ thực tế trong vòng một năm
Phát triển Driver vẫn là thử thách tối thượng
Cuộc thảo luận sôi nổi nhất tập trung vào hỗ trợ device driver, điều mà nhiều người coi là yếu tố quyết định thành bại của bất kỳ kernel mới nào. Các thành viên cộng đồng chỉ ra nhận xét sâu sắc của Linus Torvalds từ nhiều thập kỷ trước về việc phát triển driver là hào phòng thủ bảo vệ Linux. Thử thách không chỉ là dịch thuật kỹ thuật - mà còn về việc kiểm thử phần cứng và bảo trì.
Một nhà phát triển đã nêu bật một điểm nghẽn quan trọng: Ngay cả việc dịch thuật bởi một kỹ sư có tay nghề cao cũng có thể gặp vấn đề nếu họ không thực sự có phần cứng để kiểm thử. Vấn đề kiểm thử này trở nên phức tạp hơn khi xem xét những phần cứng kỳ quặc, không chuẩn mà hầu như không hoạt động với các driver Windows hiện có, chứ đừng nói đến những driver mới được chuyển đổi.
Cộng đồng đang khám phá các giải pháp sáng tạo, bao gồm dịch thuật driver hỗ trợ AI và các cách tiếp cận ảo hóa tương tự như việc HongMeng kernel sử dụng User-Mode Linux. Tuy nhiên, các mối quan ngại về bản quyền nảy sinh vì các driver Linux được chuyển đổi sẽ cần duy trì bản quyền GPLv2.
Triết lý thiết kế Framekernel đang bị xem xét kỹ lưỡng
Cách tiếp cận của Asterinas trong việc chia code kernel thành các thành phần có đặc quyền (unsafe Rust) và không có đặc quyền (safe Rust) đã tạo ra sự nhầm lẫn và tranh luận. Thuật ngữ này ban đầu có vẻ ngược đối với nhiều nhà phát triển, những người mong đợi sự phân tách đặc quyền truyền thống giữa kernel và user space.
Nhà phát triển chính của dự án đã làm rõ rằng điều này đề cập đến đặc quyền ngôn ngữ Rust chứ không phải đặc quyền phần cứng - framework có đặc quyền có thể sử dụng các tính năng unsafe Rust, trong khi các dịch vụ không có đặc quyền phải tuân thủ safe Rust. Thiết kế này nhằm giảm thiểu trusted computing base trong khi giữ mọi thứ trong kernel space để đạt hiệu suất.
Framekernel so với các kiến trúc truyền thống
| Kiến trúc | Vị trí mã nguồn | Hiệu suất | An toàn | Độ phức tạp |
|---|---|---|---|---|
| Monolithic | Không gian kernel | Cao | Thấp (toàn bộ không an toàn) | Trung bình |
| Microkernel | Tách kernel/user | Thấp hơn (chi phí IPC) | Cao (cô lập) | Cao |
| Framekernel | Không gian kernel (tách biệt logic) | Cao (bộ nhớ chia sẻ) | Trung bình (API an toàn) | Trung bình |
Những quan niệm sai lầm về hiệu suất Microkernel vẫn tồn tại
Một phần đáng kể của cuộc thảo luận xoay quanh những quan niệm lỗi thời về hiệu suất microkernel. Một số thành viên cộng đồng cho rằng các microkernel hiện đại như seL4 đã phần lớn giải quyết các vấn đề hiệu suất IPC từng làm khổ các thiết kế trước đây. Độ phức tạp của phần cứng hiện đại, với các syscall tốn kém và sự thành công của các cơ chế xếp hàng như io_uring, cho thấy rằng khoảng cách hiệu suất giữa thiết kế monolithic và microkernel có thể ít liên quan hơn so với trước đây.
Những lợi ích hiệu suất được cho là từ monolithic kernel bị lãng phí vào các tính năng bắt chước các tính năng microkernel.
Tuy nhiên, những người khác vẫn duy trì rằng việc triển khai thực tế vẫn còn thách thức, chỉ ra việc áp dụng hạn chế trong thế giới thực của các thiết kế microkernel bên ngoài các trường hợp sử dụng chuyên biệt.
Ảo hóa thay đổi cuộc chơi
Một quan điểm thú vị xuất hiện xung quanh tầm quan trọng giảm của hỗ trợ driver bare-metal trong thế giới ảo hóa ngày nay. Nhiều nhà phát triển lưu ý rằng hầu hết các instance Linux mà họ tương tác đều chạy ảo hóa, dù trong môi trường cloud, container, hay VM cục bộ. Sự thay đổi này có thể cung cấp cho Asterinas một con đường áp dụng khả thi hơn, tập trung vào các môi trường ảo hóa nơi mà tính đa dạng driver ít quan trọng hơn.
Nhóm dự án đã nhắm đến cách tiếp cận này, với kế hoạch sử dụng Asterinas như một guest OS trong Confidential VM nơi mà những lợi thế bảo mật từ memory safety và trusted computing base nhỏ trở nên có giá trị hơn so với hỗ trợ phần cứng toàn diện.
Mối quan ngại về bản quyền và hệ sinh thái
Việc lựa chọn Mozilla Public License (MPL) 2.0 thay vì GPL đã thu hút những phản ứng trái chiều từ cộng đồng. Trong khi nhóm dự án đã ghi lại lý do của họ, một số nhà phát triển bày tỏ sự ưa thích đối với các giấy phép copyleft hạn chế hơn. Quyết định bản quyền này có thể ảnh hưởng đến các mô hình áp dụng và đóng góp so với các lựa chọn thay thế được cấp phép GPL.
Dự án cho thấy triển vọng cho các trường hợp sử dụng chuyên biệt, đặc biệt trong các môi trường ảo hóa tập trung vào bảo mật. Tuy nhiên, con đường đến việc áp dụng đa mục đích vẫn còn thách thức, với việc phát triển hệ sinh thái driver có khả năng quyết định thành công hoặc thất bại cuối cùng của nó trong thị trường rộng lớn hơn.