nmbl (No More Boot Loader): dùng kernel thay cho bootloader

• Nhóm kỹ thuật bootloader của Red Hat đang phát triển một phương án mới để thay thế bootloader GRUB
• Đề xuất nmbl (no more boot loader), một giải pháp không gian người dùng dựa trên Linux, nhanh và an toàn
• Vấn đề của bootloader GRUB
  • GRUB là một bootloader mạnh mẽ và linh hoạt, được sử dụng trên nhiều kiến trúc khác nhau (x86_64, aarch64, ppc64le OpenFirmware)
  • Tuy nhiên, do tính năng phức tạp nên khó bảo trì, và trong nhiều trường hợp bị trùng lặp hoặc tụt hậu so với kernel Linux
  • Đồng thời cũng gây ra nhiều lỗ hổng bảo mật
• Ưu điểm của kernel Linux
  • Kernel Linux có cộng đồng nhà phát triển lớn, nên có thể phát triển tính năng và phản ứng với lỗ hổng nhanh chóng
  • Việc rà soát tổng thể cũng được thực hiện kỹ lưỡng hơn
• Giải pháp mới: dùng kernel làm bootloader
  • Được UEFI tải thông qua EFI stub, và được đóng gói dưới dạng Unified Kernel Image (UKI)
  • Bao gồm kernel, initramfs và dòng lệnh kernel, tức mọi thứ cần thiết để đi tới mục tiêu khởi động cuối cùng
  • Tất cả driver cần thiết, hỗ trợ hệ thống tệp và mạng đều đã được tích hợp sẵn, nhờ đó tránh trùng lặp mã

[xguru]

Ý kiến trên Hacker News

• Đã dùng UEFI từ 10 năm trước. Thời gian khởi động có rút ngắn đôi chút, nhưng bootloader có nhiều lợi ích

  • Có thể dễ dàng dual-boot với Windows
  • Có thể chỉnh sửa cmdline của kernel để khắc phục sự cố khởi động
  • Có thể dễ dàng chọn giữa nhiều kernel và image initrd
  • Có thể dễ dàng truy cập menu cài đặt UEFI
  • Có thể khởi động các ứng dụng EFI khác

• Bootloader của FreeBSD có thể khởi động mà không cần initramfs. Cần một bootloader thông minh hơn

  • Có thể hiểu ZFS và nạp trước các mô-đun cần thiết
  • Có thể hiểu phụ thuộc giữa các mô-đun và nạp trước toàn bộ mô-đun cần thiết

• Có nhiều hiểu lầm về chức năng và giới hạn của môi trường UEFI. Mọi người đang hiểu sai mục tiêu thực tế của dự án

  • Bài viết chỉ trích của Lennart nêu ra những mối lo ngại thú vị hơn

• Gợi nhớ đến MILO, thứ từng được dùng để khởi động Linux trên các hệ thống DEC Alpha vào thập niên 90

  • Cần một bootloader trung gian và một chu kỳ phát hành ưu tiên tính ổn định
  • Cần một lớp menu/cấu hình dựa trên dữ liệu

• Trước đây đã dùng Linux+Coreboot trên Chromebook. Do lỗi driver trong Tianocore UEFI BIOS nên đã dùng Linux trực tiếp

  • Đã viết một Rust TUI để mount mọi phân vùng và kexec image kernel
  • Nghĩ rằng không cần phải nhân đôi toàn bộ driver

• Nên tận dụng nhiều hơn các tính năng của UEFI và Linux. ZFSBootMenu đã cung cấp ứng dụng EFI trong 4 năm qua

  • Giai đoạn khởi động kernel đầu tiên mất khoảng 1,5~2 giây

• Có lo ngại về vấn đề tương thích với kexec

  • Ví dụ, mô-đun NVidia phải được unload trước khi kexec
  • Cũng có các vấn đề về ACPI và tương thích
  • Phỏng đoán rằng cơ chế kexec hẳn đã được thiết kế để hỗ trợ nhiều phiên bản kernel khác nhau

• EFI stub chỉ cần thiết lập multi-boot, kernel và initrd rồi nhảy tiếp là đủ đơn giản

  • Không cần một loader trung gian trở nên quá lớn và phức tạp
  • Không cần đưa cả Linux vào chỉ để tránh UEFI API và một môi trường lập trình khác

• Tò mò liệu giải pháp được đề xuất có thể xử lý khởi động đa OS hay không

  • grub có thể khởi động Linux, Windows và cả OS thứ ba
  • Lo ngại giải pháp của Red Hat sẽ bị giới hạn chỉ cho mục đích thương mại
  • Khó hiểu nó đang giải quyết vấn đề gì đối với các hệ thống chỉ khởi động lại một hoặc hai lần mỗi năm

• Không hiểu vì sao phải dùng giải pháp này thay vì EFISTUB thuần

  • Đang dùng EFISTUB trên Arch, và dùng menu BIOS khi cần khởi động Windows
  • Không hiểu lợi ích của bootloader dựa trên Linux