Cộng đồng Rust hiện đang thảo luận về thư viện mem-isolate mới được phát hành, thư viện này hứa hẹn sẽ chạy mã không an toàn một cách an toàn thông qua kỹ thuật cô lập các hoạt động tiềm ẩn nguy hiểm trong các tiến trình được tạo ra bằng fork. Mặc dù cách tiếp cận này khá thông minh, các chuyên gia về bảo mật và lập trình hệ thống đã nêu ra những lo ngại đáng kể về những hạn chế và khả năng sử dụng sai mục đích của nó.
mem-isolate hoạt động bằng cách thực thi các hàm trong các tiến trình con được cô lập, được tạo ra thông qua lệnh gọi hệ thống POSIX fork(). Cách tiếp cận này tạo ra một bản sao của bộ nhớ tiến trình cha, cho phép các hoạt động không an toàn chạy mà không ảnh hưởng đến không gian bộ nhớ của tiến trình gốc. Khi hàm hoàn thành, kết quả được chuyển đổi thành chuỗi và gửi lại cho tiến trình cha thông qua một pipe, và tiến trình con kết thúc.
Hạn chế về bảo mật
Các chuyên gia bảo mật trong cộng đồng đã chỉ ra rằng mem-isolate không thực sự cung cấp mức độ an toàn như tên gọi của nó. Thư viện này không đáp ứng định nghĩa về mã an toàn của Rust, vốn yêu cầu cả hai đảm bảo về an toàn bộ nhớ không gian và thời gian.
Tôi không nghĩ rằng điều này đáp ứng định nghĩa về an toàn trong Rust an toàn: an toàn không chỉ có nghĩa là không bị sập do lỗi bộ nhớ không gian, mà còn có nghĩa là mã thực sự an toàn về bộ nhớ cả về không gian và thời gian.
Từ góc độ bảo mật, sự cô lập được cung cấp chỉ là bề ngoài. Tiến trình được fork duy trì một bản sao hoàn chỉnh của trạng thái chương trình, bao gồm cả bất kỳ thông tin bí mật nào trong bộ nhớ. Điều này có nghĩa là mã không an toàn có thể khai thác vẫn có thể truy cập thông tin nhạy cảm trong môi trường cô lập. Ngoài ra, tiến trình con vẫn duy trì các đặc quyền giống như tiến trình cha, vì vậy các lỗ hổng thực thi mã vẫn có thể bị khai thác.
Những hạn chế chính của mem-isolate:
- Chỉ hoạt động trên các hệ thống POSIX (Linux, macOS, BSD)
- Tạo ra khoảng 1.9ms độ trễ cho mỗi lần gọi hàm (so với 1.5ns đối với gọi trực tiếp)
- Yêu cầu tuần tự hóa dữ liệu trả về giữa các tiến trình
- Tiềm ẩn nguy hiểm trong các ứng dụng đa luồng
- Không ngăn chặn được các lỗ hổng không gây ra sự cố
- Tiến trình con có cùng đặc quyền và quyền truy cập vào bộ nhớ như tiến trình cha
- Có thể gây ra tình trạng deadlock nếu fork trong khi đang giữ mutex
Những lo ngại kỹ thuật với Fork
Các chuyên gia lập trình hệ thống đã nhấn mạnh rằng fork() là một API có vấn đề cho trường hợp sử dụng này, đặc biệt là trong các ứng dụng đa luồng. Khi một tiến trình fork, toàn bộ trạng thái bộ nhớ được sao chép, bao gồm cả trạng thái của các mutex và khóa. Nếu bất kỳ luồng nào đang giữ khóa tại thời điểm fork, tiến trình con có thể gặp phải tình trạng deadlock.
Ngay cả những hoạt động đơn giản như in hoặc cấp phát bộ nhớ cũng có thể gây đóng băng trong tiến trình được fork. Các bộ đệm không gian người dùng không được xả trước khi callback hoàn thành sẽ bị mất. Những vấn đề này làm cho mem-isolate có thể gây nguy hiểm trong các ứng dụng phức tạp.
Ảnh hưởng đến hiệu suất
Thư viện này tạo ra một chi phí hiệu suất đáng kể, với các điểm chuẩn cho thấy rằng execute_in_isolated_process() mất khoảng 1.9ms so với 1.5ns cho một lệnh gọi hàm trực tiếp – chậm hơn hơn một triệu lần. Mặc dù tác giả thừa nhận hạn chế này với một nhận xét hài hước về việc chạy mã chậm hơn 1ms, các thành viên cộng đồng chỉ ra rằng chi phí này làm cho thư viện không thực tế cho nhiều trường hợp sử dụng.
Nhiều nhà phát triển sử dụng mã không an toàn đặc biệt để tối ưu hóa hiệu suất, vì vậy việc bọc mã như vậy trong một cơ chế tạo ra chi phí đáng kể sẽ làm mất đi mục đích ban đầu. Như một người bình luận đã lưu ý, việc sử dụng cách tiếp cận này một cách rộng rãi có thể phủ nhận lợi thế hiệu suất của Rust so với các ngôn ngữ như Python hoặc Ruby vốn phụ thuộc nhiều vào fork cho tính song song.
Các chỉ số hiệu suất:
- Gọi hàm trực tiếp: ~1.5ns
- fork() + wait: ~1.7ms
- execute_in_isolated_process(): ~1.9ms
Ứng dụng thực tế
Mặc dù có những hạn chế, một số nhà phát triển thấy giá trị trong mem-isolate cho các kịch bản cụ thể. Thư viện này có thể hữu ích khi làm việc với mã của bên thứ ba vốn không an toàn và không thể được cải thiện, đặc biệt là khi giao tiếp với các thư viện C. Trong những trường hợp này, sự cô lập được cung cấp có thể là một sự đánh đổi chấp nhận được để tăng thêm sự an toàn, đặc biệt là trong các đường dẫn không quan trọng về hiệu suất.
Tuy nhiên, đối với hầu hết các ứng dụng, các chuyên gia khuyến nghị các cách tiếp cận cô lập mạnh mẽ hơn. Các kiến trúc đa tiến trình được thiết kế đúng cách với các kênh IPC hạn chế và các API sandboxing cấp hệ điều hành cung cấp đảm bảo bảo mật mạnh mẽ hơn. Các công cụ trình duyệt như Chrome sử dụng cách tiếp cận này thay vì cô lập tiến trình đơn giản.
Cuộc thảo luận xung quanh mem-isolate nhấn mạnh những thách thức liên tục trong việc cân bằng an toàn, hiệu suất và tính thực tế trong lập trình hệ thống. Mặc dù các cách tiếp cận đổi mới để bảo mật bộ nhớ được hoan nghênh trong hệ sinh thái Rust, chúng phải được đánh giá cẩn thận dựa trên các phương pháp tốt nhất và mô hình bảo mật đã được thiết lập.
Tham khảo: mem-isolate: Run unsafe code safely