Pembaruan OTA untuk Linux Tertanam, bagian 1 – Dasar-dasar dan implementasi

Perlunya pembaruan

Setelah produk Linux Tertanam meninggalkan lab dan memasuki dunia nyata, pertanyaan tentang cara memperbarui perangkat akan menjadi penting untuk dipertimbangkan.

Pembaruan tidak selalu diperlukan, tetapi sulit untuk memikirkan perangkat lunak apa pun yang tidak memiliki bug yang ditemukan di beberapa titik. Meskipun perangkat lunak Anda sempurna, jika perangkat berkomunikasi di jaringan atau internet dengan pustaka sumber terbuka apa pun, pembaruan keamanan mungkin menjadi kebutuhan.

Ambil contoh CVE-2104-01650 (Hati berdarah). Kerentanan ini mempengaruhi perpustakaan kriptografi OpenSSL dan dengan ekstensi dua pertiga dari situs web di internet. Bahkan sekarang, tiga tahun kemudian, ada banyak perangkat Linux Tertanam yang menjalankan versi OpenSSL yang tidak dipertahankan, terbuka lebar untuk diserang.

Blokir vs pembaruan file

Saat berbicara tentang memperbarui Linux, Anda mungkin melihat sistem pembaruan "blok" dan "file" disebutkan. Ini mengacu pada memperbarui seluruh partisi sekaligus dengan menulis langsung ke perangkat blok atau memperbarui file individual untuk melakukan pembaruan. Anda mungkin familiar dengan sistem pembaruan file dari Desktop atau Server Linux (“sudo apt-get upgrade” misalnya).

Di Linux Tertanam, pemutakhiran berbasis blok adalah cara yang harus dilakukan karena atomisitasnya dan fakta bahwa seluruh sistem file biasanya merupakan keluaran dari sistem pembangunan Linux Tertanam. Kami berharap ruang penyimpanan pada setiap perangkat yang disematkan konstan untuk produk tertentu, jadi kami membuat partisi dengan ukuran yang sama setiap kali. Jenis pembaruan ini berjalan seiring dengan memiliki semacam fall-back atau recovery image.

Pemulihan jika terjadi kegagalan

Kami tidak pernah ingin perangkat dibiarkan dalam keadaan tidak dapat digunakan (jika, misalnya, terjadi pemadaman listrik). Kami dapat mengatasi ini dengan memastikan bahwa selalu mungkin untuk "mundur" ke partisi lain jika terjadi kesalahan dalam proses pembaruan.

Gambar 1. Pemulihan jika terjadi kegagalan – opsi mundur (Sumber:ByteSnap)

Di atas Anda dapat melihat dua kemungkinan implementasi mode mundur jika terjadi pemadaman listrik. Di sisi kiri, Bootloader mem-boot partisi penyelamat, yang kemudian mem-boot ke partisi utama. Di sisi kanan, Bootloader mem-boot salah satu dari dua partisi berdasarkan sakelar.

Bootloader harus menerapkan beberapa metode untuk menentukan apakah boot telah berhasil, dan jika belum, bootloader harus kembali ke partisi penyelamatan (diagram kiri), atau partisi kerja sebelumnya (diagram kanan).

Metode penyelamatan (kiri) memungkinkan lebih banyak ruang yang akan disediakan untuk Partisi Utama, sedangkan metode dual-rootfs (kanan) membutuhkan ruang untuk dibagi kurang lebih merata antara dua partisi. Jika ruang tidak menjadi masalah, maka disarankan untuk menggunakan metode dual-rootfs, hanya karena akan menghasilkan lebih sedikit waktu henti. Memperbarui melalui metode penyelamatan memerlukan dua reboot, satu ke partisi penyelamatan dan kemudian kembali ke utama. Metode dual-rootfs hanya memerlukan satu reboot karena pembaruan dapat dilakukan kapan saja.

Apa yang tidak dapat Anda perbarui dengan aman di sistem ini adalah bootloader (atau memang partisi penyelamat). Jika Anda ingin dapat memperbarui bootloader juga, Anda memerlukan dua partisi bootloader terpisah, dan semacam Board-Management-Controller untuk menerapkan logika peralihan di antara keduanya.

Gambar 2. Pemulihan jika terjadi kegagalan – Board Management Controller (Sumber:ByteSnap)

Ini tentu saja merupakan solusi yang rumit, memerlukan mikrokontroler tambahan, satu set firmware baru, dan desain perangkat keras yang lebih rumit (digunakan di beberapa perangkat, yang berisi pengontrol Intelligent Platform Management Interface (IPMI) terpisah, misalnya) . Oleh karena itu, Anda harus bertujuan untuk membuat bootloader yang fungsional, cakupannya kecil, dan karenanya tidak perlu diperbarui.

Variabel lingkungan U-Boot

U-boot mengimplementasikan "lingkungan" non-volatil di mana variabel dapat disimpan. Ini bahkan dapat diakses dari Linux (dalam berbagai cara, tergantung pada bagaimana lingkungan disimpan, seperti yang dijelaskan di elinux.org.

Ini adalah cara paling jelas untuk menerapkan "saklar" yang dijelaskan di atas. Ini juga dapat digunakan untuk menyimpan informasi tentang keberhasilan atau kegagalan boot sebelumnya, sehingga jika terjadi kegagalan boot, sakelar dapat dibalik dan partisi yang berfungsi dipulihkan.

Gambar 3. Variabel lingkungan U-boot (Sumber:ByteSnap)