Skip to content

U-Boot 2026: verified boot không còn dừng ở chữ ký kernel

U-Boot

Qua bốn bản release năm 2026, U-Boot chuyển từ "ký kernel là đủ" sang bảo vệ cả chuỗi khởi động: mở rộng chuỗi tin cậy tới rootfs, loại bỏ các đường vòng và xem mọi dữ liệu trên boot media là không đáng tin.

Bài này tổng hợp từ lịch sử git của U-Boot (tag v2025.10 đến v2026.10) và cover letter của các patch series đã merge. Bài giữ ở mức khái niệm, không đi vào cấu hình cụ thể. Khái niệm nền (chain of trust, TrustZone, TF-A, OP-TEE) được trình bày ở trang Secure boot và TrustZone: khái niệm cơ bản.

Tóm tắt

  • Chuỗi tin cậy phủ tới rootfs. FIT image mang được tham số dm-verity, U-Boot chuyển root hash cho kernel, và kernel kiểm tra rootfs từng block khi đọc. Một lỗ hổng cho phép bỏ qua toàn bộ cơ chế này đã được phát hiện và vá ngay trong cùng chu kỳ release.
  • Đường vòng bị chặn. Secure falcon mode bỏ fallback, file phụ chưa ký và environment khỏi đường boot nhanh từ SPL.
  • Parser được hardening. Hàng loạt bản vá cho mã đọc FIT, filesystem và giải nén, theo nguyên tắc: dữ liệu chưa được chữ ký bao phủ thì không được tin.
  • Cô lập bằng phần cứng. Firewall DDR chặn thế giới thường truy cập vùng nhớ của TF-A và OP-TEE.

1. Bối cảnh: chain of trust và những chỗ hở

Secure boot dựa trên một chuỗi: mỗi tầng xác minh chữ ký của tầng sau trước khi trao quyền điều khiển. Chuỗi chỉ mạnh bằng mắt xích yếu nhất, nên một tầng không kiểm tra, hay một đường đi vòng qua bước kiểm tra, cũng đủ vô hiệu hóa các tầng còn lại.

Chuỗi tin cậy U-Boot trước và sau 2026

Trên: trước 2026, verified boot mặc định dừng ở kernel, rootfs nằm ngoài chuỗi và có nhiều đường vòng. Dưới: sau v2026.10, mỗi chỗ hở có một cơ chế tương ứng.

"Ký kernel" nghĩa là gì

Verified boot của U-Boot xoay quanh FIT image (Flat Image Tree): một container gói kernel, device tree, ramdisk và các thành phần khác. "Ký kernel" trong U-Boot gồm hai giai đoạn:

  • Khi build: công cụ mkimage tính hash của từng thành phần trong FIT, rồi dùng private key ký node configuration, tức node chỉ định bộ kernel, device tree và ramdisk được boot cùng nhau. Chữ ký được ghi vào chính FIT.
  • Khi boot: U-Boot dùng public key để xác minh chữ ký của configuration, rồi so hash của từng thành phần với giá trị nằm trong vùng đã ký. Chỉ khi mọi kiểm tra đều khớp, U-Boot mới chuyển quyền điều khiển cho kernel.

Public key không thể nằm trong FIT, vì kẻ tấn công có thể thay key cùng lúc với image. U-Boot lưu public key trong device tree điều khiển của chính nó (node /signature). Bản thân U-Boot lại được tầng trước xác minh, và cuối cùng chuỗi được neo vào hash của root key ghi trong eFuse hoặc OTP của SoC (xem bài Rockchip RK3399 secure eFuse).

U-Boot ký configuration thay vì ký riêng từng image để chống tấn công mix-and-match. Nếu chỉ từng image được ký, kẻ tấn công có thể ghép một kernel và một device tree, cả hai đều có chữ ký hợp lệ, thành một tổ hợp mà nhà sản xuất chưa từng phát hành.

"Là đủ" và hai điểm yếu

Cụm "ký kernel là đủ" chỉ quan niệm cho rằng khi kernel và device tree đã được xác minh thì toàn bộ hệ thống đáng tin. Thực tế, phạm vi kiểm tra của U-Boot kết thúc tại thời điểm chuyển quyền cho kernel; những gì kernel nạp sau đó, trước hết là rootfs, nằm ngoài phạm vi này. Mô hình có hai điểm yếu mang tính hệ thống:

  1. Rootfs không nằm trong chuỗi mặc định. Rootfs thường có dung lượng hàng trăm MB, việc để U-Boot hash toàn bộ khi khởi động tốn quá nhiều thời gian. Bảo vệ rootfs bằng dm-verity vốn đã khả thi, nhưng mỗi dự án phải tự đưa root hash vào một thành phần đã ký, chẳng hạn initramfs, và U-Boot không hỗ trợ trực tiếp. Vì vậy, trên nhiều sản phẩm, chuỗi tin cậy thực tế dừng ở kernel.
  2. Đường vòng. Có những luồng boot nạp dữ liệu chưa được chữ ký bao phủ: fallback khi lỗi, file phụ nạp riêng, environment có thể ghi, và metadata trong FIT nằm ngoài vùng ký.

Các thay đổi trong năm 2026 có thể xem là một nỗ lực có hệ thống nhằm khắc phục hai điểm yếu này.

2. Nhịp release 2026

U-Boot duy trì chu kỳ phát hành theo quý, vào thứ Hai đầu tiên của tháng 1, 4, 7 và 10. Mỗi chu kỳ gồm một merge window khoảng ba tuần, sau đó các bản rc được phát hành cách nhau hai tuần.

Bản Ngày phát hành Commit (không tính merge) Người đóng góp
v2026.01 05/01/2026 ~1.185 ~196
v2026.04 06/04/2026 ~1.050 ~179
v2026.07 06/07/2026 ~1.329 ~221
v2026.10 05/10/2026 ~1.346 ~199

Song song với phần mã, dự án chuyển hạ tầng khỏi máy chủ của DENX sang mailing list và GitLab riêng. v2026.10 là bản đầu tiên phát hành hoàn toàn trên hạ tầng mới.

Các thay đổi bảo mật trải đều qua cả năm: secure falcon vào v2026.01, firewall vùng nhớ TEE vào v2026.04 và v2026.07, còn dm-verity cùng phần lớn bản vá parser vào v2026.10.

3. Kéo chuỗi tin cậy tới rootfs: dm-verity trong FIT

Ý tưởng

Thay vì hash toàn bộ rootfs, U-Boot chỉ cần xác thực một giá trị duy nhất là root hash, rồi giao việc kiểm tra dữ liệu cho kernel. Bản thân dm-verity không mới; điểm mới của v2026.10 là FIT có định dạng chuẩn để mang root hash, và U-Boot tự xử lý phần chuyển giao cho kernel thay vì để mỗi dự án tự dựng.

  • Rootfs (squashfs hoặc erofs, chỉ đọc) được đặt trong FIT, kèm một cây hash Merkle nằm ngay sau dữ liệu.
  • Một node dm-verity trong FIT chứa root hash, salt và kích thước block.
  • U-Boot xác minh chữ ký configuration, rồi sinh tham số dòng lệnh kernel cho device-mapper (dm-mod.create=).
  • Kernel dựng thiết bị dm-verity. Mỗi khi đọc một block, kernel hash block đó và đối chiếu ngược lên tới root hash. Nếu block đã bị sửa đổi, hash sẽ không khớp và thao tác đọc trả về lỗi I/O.

Luồng dm-verity trong FIT image

U-Boot chỉ xác minh chữ ký; việc kiểm tra dữ liệu rootfs diễn ra trong kernel, theo từng block, tại thời điểm đọc.

Chi phí của tính năng thấp. Tính năng được điều khiển bởi CONFIG_FIT_VERITY: khi tắt, kích thước binary không thay đổi; khi bật, binary tăng khoảng 3 kB. Thời gian boot cũng gần như không đổi, vì việc kiểm tra được phân bổ theo các lần đọc thay vì tập trung vào lúc khởi động.

Nguồn gốc: OpenWrt

Tính năng do Daniel Golle, nhà phát triển OpenWrt, đóng góp. Mô hình firmware của OpenWrt nhúng rootfs chỉ đọc trực tiếp vào FIT, và kernel map rootfs này trực tiếp từ thiết bị lưu trữ qua driver fitblk, không cần chép vào RAM. Đây là phần đầu tiên được tách ra từ một loạt patch lớn hơn về "OpenWrt boot method". Schema của node dm-verity cũng được đưa vào đặc tả flat-image-tree, nên các công cụ khác có thể dùng chung định dạng.

Case study: tính năng bảo mật thiếu chữ ký

dm-verity được merge vào nhánh phát triển cuối tháng 5/2026. Khoảng hai tháng rưỡi sau, vào đầu tháng 8, chính tác giả gửi series "authenticate the dm-verity roothash" để vá một lỗ hổng; series này được đưa vào v2026.10-rc2. Nguyên nhân: khi xác định vùng dữ liệu được chữ ký configuration bao phủ, U-Boot đưa vào node image, các node hash và node cipher, nhưng bỏ sót node dm-verity.

Hệ quả là một cách bỏ qua verified boot cho toàn bộ rootfs. Kẻ tấn công ghi được vào boot media có thể:

  1. Thay rootfs bằng bản độc hại.
  2. Tính lại cây hash Merkle cho rootfs mới.
  3. Ghi root hash mới vào node dm-verity.

Chữ ký configuration vẫn hợp lệ, vì root hash không nằm trong vùng ký. Kernel nhận root hash mới, và dm-verity xác nhận rootfs độc hại là hợp lệ.

Bài học rút ra: một cơ chế bảo mật chỉ mạnh bằng neo tin cậy của nó. Về mặt thuật toán, dm-verity không có lỗi; nhưng khi root hash không được ký, cơ chế này chỉ chứng minh rằng rootfs khớp với một giá trị do chính kẻ tấn công chọn. Bản vá được merge trước khi v2026.10 phát hành, nên không có bản release chính thức nào chứa lỗ hổng này. Các dự án backport dm-verity về cây mã riêng cần backport kèm bản vá này.

4. Bịt đường vòng: secure falcon mode

Falcon mode là gì

Trong luồng boot thông thường, SPL nạp U-Boot proper, sau đó U-Boot proper nạp kernel. Falcon mode cho phép SPL nạp trực tiếp kernel, bỏ qua U-Boot proper để rút ngắn thời gian boot. Trên SoC TI K3, chuỗi R5 SPL → TF-A → OP-TEE → A-core SPL → U-Boot → Linux rút gọn thành R5 SPL → TF-A → OP-TEE → A-core SPL → Linux.

Bốn đường vòng

Khi đưa falcon mode lên TI K3, tác giả (Anshul Dalal, TI) chỉ ra rằng dù SPL có thể nạp FIT đã ký, luồng falcon vẫn có bốn chỗ cho phép bỏ qua verified boot:

Đường vòng Vì sao nguy hiểm Cách xử lý
Falcon lỗi thì fallback sang boot thường Kẻ tấn công chỉ cần làm hỏng image falcon để buộc hệ thống chuyển sang luồng boot khác Dừng boot khi lỗi, không fallback
File args (thường là DTB) nạp riêng File này không có cơ chế xác minh Bỏ file args, DTB phải nằm trong FIT đã ký
Đọc environment để lấy tên file Environment nằm trên media có thể ghi Không dùng environment
Cho phép boot raw image Raw image không có chữ ký Chỉ chấp nhận FIT

Falcon mode và secure falcon mode

Secure falcon chỉ giữ lại một luồng duy nhất: FIT đã ký, chứa cả kernel và DTB. Lỗi ở bất kỳ bước nào cũng dẫn đến dừng boot.

Theo góp ý của maintainer, thay đổi được tách thành nhiều series nhỏ và lần lượt được merge trong chu kỳ v2026.01. Kết quả là tùy chọn SPL_OS_BOOT_SECURE, kèm tài liệu dùng AM62x EVM làm ví dụ.

Bài học ở đây mang tính tổng quát: cơ chế fallback nhằm tăng tính tiện dụng thường lại chính là lỗ hổng. Với mỗi nhánh dự phòng trong boot chain, cần kiểm tra xem luồng thay thế có được xác minh hay không.

5. Không tin dữ liệu chưa xác minh: hardening parser

Đây là hướng có nhiều bản vá nhất, nhưng cũng ít được chú ý nhất vì không gắn với một tính năng cụ thể.

Nguyên tắc

Kẻ tấn công trong mô hình secure boot là người ghi được vào boot media (flash, eMMC, thẻ SD). Mọi dữ liệu U-Boot đọc từ các thiết bị này đều có thể đã bị sửa đổi. Chữ ký bảo vệ phần được ký, nhưng để tìm và kiểm tra phần được ký, U-Boot phải đọc một số dữ liệu trước khi chữ ký được xác minh, hoặc dữ liệu không nằm trong vùng ký. Mã đọc những dữ liệu đó phải chịu được đầu vào độc hại.

Các ví dụ trong năm 2026

  • Metadata của FIT (Binarly, v2026.10). Các trường cho biết dữ liệu ngoài nằm ở đâu và dài bao nhiêu không được chữ ký bao phủ, nhưng lại bị đọc như số có dấu và dùng trong phép tính không chống tràn. Bản vá chuyển sang số không dấu, thêm phép tính an toàn và kiểm tra phạm vi, đặc biệt trong SPL vốn có ít kiểm tra hơn.
  • VBE đọc trước khi xác minh (Canonical, v2026.10). Verified Boot for Embedded đọc firmware từ một vùng cố định, với vị trí và độ dài lấy từ chính FIT, và lần đọc này xảy ra trước khi kiểm tra chữ ký. Bản vá giới hạn lần đọc trong vùng firmware. Hướng sửa triệt để hơn là "xác minh xong mới nạp" đã được thảo luận và dời sang một series sau.
  • Giải nén kernel (Canonical, v2026.10). Bộ đệm giải nén được cấp theo kích thước ước lượng, nhưng giới hạn truyền cho bộ giải nén lại lớn hơn nhiều. Một payload có tỷ lệ nén cao có thể ghi tràn sang device tree, ramdisk hoặc dữ liệu của chính U-Boot.
  • Filesystem. Đọc ngoài vùng nhớ và tràn số nguyên trong SquashFS, do tin vào offset nằm trong image (v2026.10). Mã filesystem nói chung chuyển sang dùng các hàm kiểm tra tràn của trình biên dịch (v2026.04).
  • Device tree. Kiểm tra độ dài property trước khi dùng khi U-Boot sửa device tree trước khi boot kernel (v2026.10).

Những bên đóng góp bản vá

Người gửi các bản vá này gồm một công ty chuyên bảo mật firmware (Binarly), Canonical và các nhà nghiên cứu độc lập. Cách họ mô tả lỗi cũng đáng chú ý: không phải "crash khi gặp image hỏng" mà là "giá trị do kẻ tấn công kiểm soát, đến được trước bước kiểm tra chữ ký". U-Boot đang được audit với tư duy bề mặt tấn công, giống cách UEFI firmware đã được audit trong nhiều năm.

6. Cô lập bằng phần cứng: firewall vùng nhớ TEE

Chữ ký hợp lệ chưa đủ để bảo đảm an toàn. Sau khi boot hoàn tất, TF-A và OP-TEE vẫn nằm trong DDR; nếu Linux đọc hoặc ghi được vùng nhớ này, mọi bảo đảm của TEE đều mất.

  • Firewall ATF/OP-TEE trên TI Sitara (v2026.04). Cấu hình firewall phần cứng để thế giới thường không truy cập được vùng DDR của TF-A và OP-TEE. Địa chỉ các vùng nhớ được chuyển sang Kconfig, nhờ đó khi thay đổi vị trí của TF-A hoặc OP-TEE, không cần sửa thủ công cấu hình firewall.
  • Truy cập suy đoán (v2026.07). Sau khi bật firewall, CPU A53 trên dòng AM62 gây exception vì tự truy cập suy đoán vào vùng secure. Phần mềm không truy cập vùng này, nhưng CPU có thể nạp trước dữ liệu từ mọi vùng được map trong MMU. Bản vá bỏ map các vùng này.

Trường hợp thứ hai cho thấy cô lập không chỉ là cấu hình firewall: bảng trang của bootloader cũng phải phản ánh đúng ranh giới secure.

7. Hàm ý cho đội phát triển sản phẩm

Nếu sản phẩm dùng verified boot với U-Boot:

  1. Cập nhật lên v2026.10 hoặc backport các bản vá metadata FIT, SquashFS, giải nén kernel và VBE. Chúng không đổi hành vi với image hợp lệ, chỉ từ chối image bị làm giả.
  2. Khi dùng dm-verity, bắt buộc phải có bản vá ký root hash. Thiếu bản vá này, dm-verity gần như không có tác dụng trước kẻ tấn công ghi được flash.
  3. Khi dùng falcon mode cho sản phẩm yêu cầu bảo mật, cần bật secure falcon. Falcon mode thường được dùng trên thiết bị cần boot nhanh, và đây cũng là nơi dễ bỏ sót đường vòng.
  4. Rà lại mọi đường fallback trong cấu hình: lệnh boot dự phòng, environment ghi được từ media, các lệnh nạp file không qua FIT.
  5. Kiểm tra cô lập TEE trên SoC có firewall: xác nhận vùng nhớ TF-A và OP-TEE thực sự bị chặn với thế giới thường và đã được loại khỏi bảng trang.

8. Kết luận

Năm 2026 không có một "tính năng bảo mật lớn" duy nhất cho U-Boot, nhưng có một hướng đi nhất quán: chuyển từ "ký kernel" sang "mọi byte ảnh hưởng tới boot đều phải được xác minh hoặc bị nghi ngờ". dm-verity kéo chuỗi xuống rootfs, secure falcon bỏ đường vòng, hardening parser xử lý dữ liệu chưa xác minh, firewall cô lập TEE.

Trường hợp root hash chưa được ký là ví dụ điển hình nhất: một tính năng bảo mật không bao phủ neo tin cậy của nó sẽ mất tác dụng. Bước tiếp theo đã được đề cập trong thảo luận về VBE: chuyển hoàn toàn sang mô hình "xác minh trước, nạp sau". v2027.01 hiện đang trong merge window, và tiến triển của hướng này cần được tiếp tục theo dõi.

Nguồn tham khảo