OTA Update¶

OTA (over-the-air) update là khả năng cập nhật phần mềm cho thiết bị đã triển khai mà không cần người tới tận nơi. Với IoT đây là yêu cầu bắt buộc: thiết bị sống nhiều năm và lỗ hổng sẽ được phát hiện trong suốt thời gian đó. Các quy định như EU Cyber Resilience Act cũng yêu cầu nhà sản xuất cung cấp bản vá bảo mật (xem IoT Security & Compliance).

Yêu cầu cốt lõi của một hệ thống OTA:

Không bao giờ để thiết bị thành cục gạch: mất điện giữa chừng hay bản cập nhật lỗi đều phải quay về được trạng thái chạy được.
Chỉ chạy phần mềm được ký: thiết bị kiểm tra chữ ký trước khi cài.
Nguyên tử (atomic): thiết bị chạy hoặc bản cũ, hoặc bản mới, không bao giờ một nửa.
Quản lý được hàng loạt: biết thiết bị nào chạy bản nào, triển khai theo đợt, dừng khi có lỗi.

Chiến lược cập nhật¶

Chiến lược	Cách làm	Ưu điểm	Nhược điểm
Cập nhật từng package (`apt`, `opkg`)	Cài/thay từng gói trên rootfs đang chạy	Nhỏ gọn	Không nguyên tử, trạng thái thiết bị trôi dần, khó tái lập
Single copy + recovery	Khởi động vào hệ thống recovery nhỏ (initramfs) để ghi đè rootfs chính	Tiết kiệm flash	Thiết bị ngừng hoạt động trong lúc cập nhật; recovery phải luôn chạy được
A/B (dual copy)	Hai phân vùng rootfs, ghi vào bản không chạy rồi chuyển	Nguyên tử, rollback ngay, thời gian chết chỉ bằng một lần reboot	Tốn gấp đôi dung lượng rootfs
File-based (OSTree)	Lưu rootfs như kho nội dung theo hash, chuyển bằng hardlink	Tiết kiệm dung lượng, tải phần chênh lệch	Phức tạp hơn, cần filesystem phù hợp
Cập nhật ứng dụng (container)	Chỉ cập nhật image ứng dụng, OS giữ nguyên	Nhanh, tách vòng đời OS và ứng dụng	Vẫn cần một cơ chế khác để vá OS và kernel

Thực tế, gateway Linux thường dùng A/B cho OS và có thể thêm container cho ứng dụng.

Bố trí phân vùng A/B¶

+--------+------------+------------+------------------+
|  boot  |  rootfs A  |  rootfs B  |  data (bền vững) |
+--------+------------+------------+------------------+
  bootloader,  đang chạy   được ghi     cấu hình, chứng chỉ,
  env           (active)  (inactive)   dữ liệu ứng dụng

Rootfs nên ở chế độ chỉ đọc. Mọi trạng thái thay đổi nằm ở phân vùng data, nhờ đó hai slot có thể thay thế nhau.
Kernel và device tree có thể nằm trong rootfs (/boot) để được cập nhật cùng slot.
Dữ liệu ở data cần quy trình migrate khi định dạng thay đổi giữa hai phiên bản, và bản cũ phải đọc được dữ liệu đó nếu rollback.

Luồng cập nhật và rollback¶

sequenceDiagram
    participant S as OTA server
    participant D as Thiết bị (đang chạy slot A)
    participant BL as Bootloader
    D->>S: Hỏi bản mới (polling định kỳ)
    S-->>D: Bản 1.5.0, URL, hash
    D->>S: Tải bundle qua HTTPS
    D->>D: Kiểm tra chữ ký, ghi vào slot B
    D->>BL: Đặt slot B là slot khởi động, đặt bộ đếm thử
    D->>D: Reboot
    BL->>BL: Giảm bộ đếm, boot slot B
    alt Slot B chạy tốt
        D->>D: Health check đạt (service lên, kết nối được server)
        D->>BL: Mark good: slot B là slot chính
        D->>S: Báo thành công
    else Slot B lỗi (kernel panic, treo, health check thất bại)
        BL->>BL: Bộ đếm về 0 hoặc watchdog reset
        BL->>BL: Quay về boot slot A
        D->>S: Báo thất bại
    end

Bộ đếm thử nằm trong bootloader. Với U-Boot có hai cách phổ biến:

Dùng cơ chế có sẵn: bootcount, bootlimit, upgrade_available và altbootcmd. Khi bootcount vượt bootlimit, U-Boot chạy altbootcmd thay vì bootcmd.
Dùng biến riêng của công cụ OTA, ví dụ RAUC dùng BOOT_ORDER, BOOT_A_LEFT, BOOT_B_LEFT và một đoạn script trong U-Boot để chọn slot.

Phải có hardware watchdog được bật sớm (từ bootloader hoặc kernel) để thiết bị treo cũng tự reset và quay về được. Chi tiết bootloader xem U-Boot.

Health check quyết định khi nào đánh dấu bản mới là tốt. Chỉ "boot lên được" là chưa đủ: nên kiểm tra service chính đã chạy và thiết bị kết nối được về server, nếu không thì một bản cập nhật làm hỏng mạng sẽ khiến thiết bị không bao giờ nhận được bản sửa.

So sánh công cụ¶

	SWUpdate	RAUC	Mender
Mô hình	Framework, cấu hình linh hoạt	Công cụ cập nhật theo slot, chặt chẽ	Giải pháp trọn gói client + server
Định dạng gói	`.swu` (cpio), mô tả bằng `sw-description`	Bundle `.raucb` (squashfs), mô tả bằng `manifest.raucm`	Artifact `.mender`
Chữ ký	RSA, CMS, GPG	CMS với chuỗi chứng chỉ X.509	RSA, ECDSA
Chiến lược	Single copy + recovery, A/B, script tùy ý	A/B và nhiều slot	A/B
Bootloader	U-Boot, GRUB, EFI Boot Guard	U-Boot, GRUB, barebox, EFI	U-Boot, GRUB
Delta update	Handler delta dựa trên zchunk	Adaptive update (chỉ tải block thay đổi), casync	Có, ở bản thương mại
Server	Eclipse hawkBit (qua suricatta), web server nội bộ	Không đi kèm; dùng hawkBit qua `rauc-hawkbit-updater`	Mender server (mã nguồn mở hoặc dịch vụ)
Yocto	`meta-swupdate`	`meta-rauc`	`meta-mender`

Gợi ý chọn:

Cần một giải pháp có sẵn cả server và dashboard, ít tùy biến: Mender.
Muốn mô hình slot rõ ràng, chữ ký X.509 chặt chẽ, tự chọn server: RAUC + hawkBit.
Cần cập nhật nhiều thành phần lạ (FPGA bitstream, firmware MCU phụ, phân vùng raw) trong một gói, hoặc chỉ có flash cho single copy: SWUpdate.

Ví dụ với RAUC¶

Cấu hình slot trên thiết bị:

/etc/rauc/system.conf

[system]
compatible=vux-gateway-pi3
bootloader=uboot
data-directory=/data/rauc

[keyring]
path=/etc/rauc/ca.cert.pem

[slot.rootfs.0]
device=/dev/mmcblk0p2
type=ext4
bootname=A

[slot.rootfs.1]
device=/dev/mmcblk0p3
type=ext4
bootname=B

Các lệnh thường dùng:

rauc info update.raucb        # xem manifest, kiểm tra chữ ký
rauc install update.raucb     # ghi vào slot không hoạt động
rauc status --detailed        # slot nào đang boot, slot nào tốt
rauc status mark-good         # gọi từ health check sau khi boot bản mới

Trong Yocto, thêm layer meta-rauc, viết recipe bundle kế thừa bundle và chỉ định image rootfs, khóa ký. Bundle được ký lúc build bằng khóa của nhà sản xuất; khóa riêng không bao giờ được nằm trên thiết bị. Xem thêm Yocto.

Vận hành ở quy mô lớn¶

Triển khai theo đợt (staged rollout): cập nhật vài phần trăm thiết bị trước, theo dõi tỉ lệ rollback rồi mới mở rộng.
Chống hạ cấp (anti-rollback): không cho cài bản cũ có lỗ hổng đã biết. Có thể dùng số phiên bản bảo mật lưu trong eFuse hoặc vùng chống ghi đè.
Cập nhật kết hợp với secure boot: khóa ký bản cập nhật và chuỗi tin cậy khởi động nên nằm trong cùng một kế hoạch quản lý khóa. Xem Secure boot và TrustZone.
Băng thông: thiết bị dùng cellular nên ưu tiên delta update và giới hạn cửa sổ thời gian tải.
Báo cáo trạng thái: server phải biết chính xác mỗi thiết bị đang chạy bản nào, để trả lời nhanh câu hỏi "bao nhiêu thiết bị còn bị CVE này". Xem CVE.
Firmware của node: gateway có thể làm trung gian cập nhật firmware cho MCU phía dưới (BLE DFU, MCUboot). Xem MCU Node & RTOS.