Kẻ giết chết bộ chuyển mạch mạng là ai? Câu chuyện về lỗi 'Hubris'

Câu chuyện về lỗi Hubris: Ai đã giết chết bộ chuyển mạch mạng?

• Hubris là gì?

  • Hubris là một hệ điều hành dành cho các hệ thống nhúng sâu, được thiết kế cho những máy tính không được nhận diện là máy tính, như bên trong bàn phím.
  • Nó được phát triển để xử lý mọi công việc cần thiết nhằm khởi động các bộ xử lý lớn trong Oxide Rack.
  • Hubris khá độc đáo, và những phần liên quan đến câu chuyện sẽ được giải thích bên dưới.

• Hiện trường vụ án

  • Arjen Roodselaar, đồng nghiệp phụ trách firmware bộ chuyển mạch mạng của Oxide, đang thử nghiệm các thay đổi về trình tự cấp nguồn và cấu hình xung nhịp.
  • Sau một thay đổi nhỏ, đột nhiên bộ chuyển mạch không còn khởi động được nữa.
  • Một phần firmware vẫn phản hồi, nhưng phần quan trọng chịu trách nhiệm về trình tự cấp nguồn thì đã dừng lại.

• Khai thác nhiều hơn từ lượng RAM hạn chế

  • Các vi điều khiển giá rẻ dùng Hubris có RAM và flash rất hạn chế.
  • Hubris được cấu thành từ nhiều chương trình được biên dịch riêng biệt gọi là task, nên có yêu cầu tài nguyên hơi cao hơn một chút so với các hệ điều hành khác.
  • Đồng nghiệp Matt Keeter gần đây đã làm cho hệ thống thông minh hơn để cố gắng đóng gói các task nhiều nhất có thể bằng cách sử dụng nhiều vùng lũy thừa của 2.

• Khẩu súng còn bốc khói

  • Arjen đã dùng Humility, trình gỡ lỗi của Hubris, để điều tra bộ chuyển mạch mạng bị lỗi.
  • Anh dùng lệnh humility tasks để in ra danh sách các task đang chạy trên bộ xử lý cùng thông tin trạng thái.
  • Anh phát hiện task phụ trách trình tự cấp nguồn đã khởi động lại 115 lần do lỗi bộ nhớ.

• Mở rộng cơ chế mượn của Rust qua các task trong IPC của Hubris

  • Các task trong Hubris có thể gửi thông điệp cho nhau thông qua IPC.
  • Các thông điệp này trông và hoạt động rất giống lời gọi hàm.
  • Khi một task cho task khác mượn bộ nhớ, nó không được phép cố cho mượn vùng nhớ mà trên thực tế nó không sở hữu.

• Khi các tính năng quay sang tấn công

  • Hai tính năng có thể kết hợp lại và trở thành một lỗi.
  • Việc đóng gói task hoạt động theo kiểu cơ hội trong hệ thống build.
  • Nếu kích thước của task A thay đổi một chút, vị trí ranh giới vùng MPU của task B không liên quan cũng có thể bị dịch chuyển.

• Cuộc gọi từ bên trong!

  • Thuật toán bảo vệ bộ nhớ cần phải được thay đổi.
  • Cần cho phép vùng nhớ được cho mượn vượt qua ranh giới vùng MPU.

• Thất bại cùng Hubris

  • Có nhiều điều đã không xảy ra khi hệ thống gặp sự cố.
  • Bộ chuyển mạch mạng bị hỏng đã có thể được sửa chỉ trong 3 giờ.
  • Khả năng cô lập lỗi, thất bại theo hướng an toàn, bộ nhớ chia sẻ an toàn, đồng thiết kế kernel-trình gỡ lỗi, sự đơn giản trong thiết kế và triển khai, cùng sự gắn kết chặt chẽ và phi phân cấp của cả nhóm đều đã giúp ích.

Ý kiến của GN⁺

• Bài viết này cho thấy tầm quan trọng của thiết kế phần mềm vững chắc ngay cả trong các hệ thống phức tạp, thông qua quá trình tìm ra và khắc phục một lỗi phát sinh trong hệ điều hành Hubris.
• Quá trình phát hiện và sửa lỗi nhấn mạnh tầm quan trọng của làm việc nhóm và các công cụ gỡ lỗi hiệu quả trong việc giải quyết những vấn đề phức tạp của kỹ thuật phần mềm.
• Bài viết cho thấy các tính năng cô lập hệ thống và quản lý sự cố quan trọng như thế nào khi sử dụng một hệ thống như Hubris. Điều này có thể cải thiện đáng kể độ ổn định và khả năng bảo trì của hệ thống.
• Bài viết cũng cho thấy cách sử dụng Rust, một ngôn ngữ lập trình an toàn, để đảm bảo an toàn bộ nhớ và giảm thiểu lỗi. Trong các hệ thống dùng Rust, những loại lỗi như vậy hiếm khi xảy ra, và điều đó chứng minh các đảm bảo an toàn bộ nhớ của Rust thực sự hiệu quả đến mức nào.
• Những dự án hoặc sản phẩm khác có tính năng tương tự gồm seL4, FreeRTOS, Zephyr; đây đều là các hệ điều hành cho hệ thống nhúng với mục đích và đặc tính khác nhau.
• Khi áp dụng một hệ thống như Hubris, cần cân nhắc các yếu tố như giới hạn bộ nhớ, quản lý task và thiết kế cơ chế IPC. Lợi ích của việc chọn những hệ thống như vậy nằm ở thiết kế hệ thống vững chắc và quản lý bộ nhớ an toàn, còn nhược điểm có thể là độ phức tạp của hệ thống và đường cong học tập.

[GN⁺]

Ý kiến trên Hacker News

• Đánh giá mã kernel Hubris

  • Tôi đã đọc mã kernel của Hubris khoảng nửa tiếng và thấy nó rất rõ ràng, được viết rất tốt. Nó khác hẳn với kiểu mã C có macro phức tạp, tên biến hai chữ cái và ít chú thích mà tôi từng thấy trước đây. Rất đáng đọc trước khi đi ngủ.

• Lời khen cho tin tuyển dụng

  • Đây là một trong những tin tuyển dụng hay nhất mà tôi từng thấy. Phần chuyển sang nói về văn hóa rất tự nhiên rồi kết lại bằng câu "chúng tôi đang tuyển dụng". Đây thậm chí còn là một bài post-mortem rất hay mà cả lập trình viên ở tầng ứng dụng cũng có thể hiểu được. Tôi đang học Rust nên cũng đã có sự chuẩn bị cho loại nội dung này. Ngoài ra, xem công việc của người khác với rất nhiều chú thích trong mã lúc nào cũng thú vị.

• Rà soát mã và đề xuất

  • Một góp ý nhỏ về mã: vì đây là chú thích về bất biến của trường mà mọi tác giả đều cần tôn trọng và mọi người đọc đều có thể dựa vào, chứ không phải chi tiết của một hàm cụ thể, nên sẽ tốt hơn nếu thêm nó vào chuỗi tài liệu của TaskDesc::regions.

• Đánh giá về quá trình gỡ lỗi

  • Bài viết đưa ra một phân tích sâu về việc gỡ lỗi một vấn đề phức tạp, và việc phần còn lại của hệ thống vẫn ổn định là bằng chứng cho chất lượng kỹ thuật rất cao của đội ngũ Oxide. Cá nhân tôi thấy được truyền cảm hứng và dự định áp dụng các kỹ thuật tương tự ở nơi làm việc.

• Quan tâm đến văn hóa của đội ngũ Oxide

  • Đội ngũ kỹ thuật của Oxide không bị cô lập nội bộ, mà có một nền văn hóa khuyến khích sự cởi mở, tò mò và giao tiếp, đồng thời hạn chế thái độ phòng thủ, xây dựng đế chế và gatekeeping. Họ đã nỗ lực để tạo ra và gìn giữ nền văn hóa đó, và có thể thấy điều này qua cách tổ chức theo chiều ngang, băng qua phạm vi mà ở các tổ chức khác thường được gọi là các nhóm. Tôi muốn biết thêm về động lực cũng như chi tiết thực thi cụ thể để xây dựng văn hóa như vậy. Liệu việc khuyến khích "cởi mở, tò mò, giao tiếp" trong một tổ chức có mặt trái nào không, và có khi nào người ta sẽ chọn một hệ thống phân cấp chặt chẽ hơn không? Tôi cảm thấy sơ đồ tổ chức nên được quyết định một cách chiến lược, nhưng chưa rõ những đánh đổi ở đây là gì.

• Liên kết thông tin liên quan

  • Có thể tìm thông tin nền qua liên kết được cung cấp.

• Đồng cảm với vấn đề phát sinh khi gỡ lỗi

  • Tôi hoàn toàn đồng cảm rằng những lỗi crash ngẫu nhiên biến mất ngay khi thêm mã debug là kiểu tệ nhất.

• Đề xuất về cách xử lý phần cứng

  • Có ý kiến cho rằng có thể hỗ trợ hơn 8 vùng bằng cách xử lý phần cứng như một soft-fill TLB.

• Lời khen cho công việc của Oxide

  • Bày tỏ sự ấn tượng với công việc mà Oxide đang làm.

• Phản ứng với tên hệ điều hành

  • Bày tỏ sự ngạc nhiên và phản ứng trước việc đặt tên hệ điều hành là Hubris.