Arsitektur sistem firmware berbasis ARMv8

Sejak dirilis pada tahun 2011, arsitektur prosesor ARMv8 telah menjadi cukup luas di pasar perangkat seluler. Menurut perkiraan CEO ARM Limited, prosesor generasi ini akan memperoleh pangsa pasar dunia hingga 25% pada tahun 2020. Wajar jika dukungan perangkat lunak didirikan dan telah berkembang lebih lanjut dengan mewarisi fitur dan umum. prinsip-prinsip infrastruktur yang terbentuk secara historis.

Situasi yang berbeda secara fundamental diamati di segmen server pasar. Server berbasis X86 telah mendominasi area ini untuk waktu yang lama, sementara ARMv8 baru saja menemukan jalannya (dan hanya untuk segmen bisnis tertentu). Kebaruan pasar ARM ini dan fakta bahwa sebagian besar standar dan spesifikasi yang diterima (terutama ACPI dan UEFI) belum diadaptasi untuk sistem ARM hingga saat ini telah meninggalkan jejaknya pada pengembangan infrastruktur perangkat lunak.

Artikel ini berfokus pada ikhtisar tentang sistem server dan fitur prosesor berbasis ARM dan tidak mengklaim sebagai deskripsi yang lengkap. Penulis juga ingin menarik perhatian pembaca pada fakta bahwa data yang disediakan dapat dengan cepat menjadi usang – tidak lama lagi, prosesor baru akan hadir dengan solusi teknis baru yang mungkin memerlukan pendekatan berbeda untuk implementasi infrastruktur perangkat lunak.

Pertama, kami harus menunjukkan bahwa implementasi firmware saat ini untuk sistem server ARMv8 terdiri dari beberapa komponen yang relatif independen. Ini memberikan sejumlah keuntungan, seperti kemungkinan menggunakan komponen yang sama di server dan firmware sistem tertanam, serta independensi relatif dari perubahan yang diperkenalkan.

Jadi, modul dan komponen apa yang digunakan dalam sistem ini, dan apa fungsinya? Bagan keseluruhan untuk pemuatan dan interaksi modul ditunjukkan pada Gambar. 1. Proses dimulai dengan inisialisasi subsistem, seperti RAM dan antarmuka antarprosesor. Dalam implementasi saat ini, ini dijalankan oleh modul terpisah dalam mode EL3S segera setelah menyalakan daya CPU utama. Dengan demikian, komponen sistem ini memiliki hak istimewa semaksimal mungkin. Biasanya tidak berinteraksi dengan OS secara langsung.

Gbr 1. Pemuatan dan interaksi modul. (Sumber:Auriga)

Kemudian, kontrol ditransfer ke komponen berikutnya, paling sering modul ARM Trusted Firmware (ATF), yang dijalankan dalam mode yang sama. Kontrol ATF dapat ditransfer baik secara langsung dari pemuat level 0 yang dijelaskan dalam paragraf sebelumnya atau secara tidak langsung melalui modul UEFI khusus yang mengimplementasikan PEI (Inisialisasi PreEFI). ATF terdiri dari beberapa modul yang menerima kontrol pada waktu yang berbeda.

Modul mulai BL1 melakukan inisialisasi bagian platform yang ditetapkan ke mode prosesor aman. Karena sistem berbasis ARMv8 menggunakan pemisahan perangkat keras untuk sumber daya tepercaya dan tidak tepercaya, termasuk RAM, modul BL1 menyiapkan lingkungan tempat kode tepercaya dapat dieksekusi. Secara khusus, jenis inisialisasi ini mencakup konfigurasi pengontrol memori/cache (zona tepercaya dan tidak tepercaya ditandai melalui pemrograman register di perangkat ini) dan penandaan perangkat on-chip (pengontrol memori tidak bergantung energi). Markup ini juga memperkenalkan pemfilteran transaksi DMA berdasarkan jenis perangkat (tepercaya/tidak tepercaya). Mengingat semua ini, penulisan/pembacaan memori hanya dimungkinkan ke/dari area yang pengaturan keamanannya cocok dengan perangkat. Implementasi lingkungan tepercaya bisa sangat kompleks; misalnya, mereka dapat menyertakan OS terpisah. Namun, deskripsi implementasi tersebut berada di luar cakupan artikel ini.

Modul BL1 mengonfigurasi tabel terjemahan alamat MMU, serta tabel exception handler, di mana elemen terpenting adalah exception handler untuk instruksi Secure Monitor Call (SMC). Pada titik ini, handler minimal dan sebenarnya hanya dapat mentransfer kontrol ke gambar yang dimuat ke dalam RAM. Saat berjalan, modul BL1 memuat tahap berikutnya (BL2) ke dalam RAM dan mentransfer kontrol ke sana. Modul BL2 bekerja dalam mode EL1S dengan hak istimewa yang dikurangi. Oleh karena itu, transfer kontrol ke modul ini dilakukan dengan menggunakan instruksi “ERET”.

Tujuan dari modul BL2 adalah untuk memuat modul firmware yang tersisa (bagian BL3) dan mentransfer kontrol ke modul tersebut. Tingkat hak istimewa yang dikurangi digunakan untuk menghindari kemungkinan kerusakan pada kode dan data EL3S yang sudah ada di memori. Kode bagian ini dijalankan dengan memanggil kode EL3S yang terletak di tahap BL1 menggunakan instruksi SMC.

Tahap ketiga pemuatan dan inisialisasi ATF dapat terdiri dari tiga tahap, tetapi tahap kedua biasanya dihilangkan. Jadi, sebenarnya, hanya dua yang tersisa. Modul BL3-1 adalah bagian dari kode tepercaya yang dapat diakses oleh perangkat lunak serba guna (OS, dll.) saat runtime. Bagian penting dari modul ini adalah exception handler yang dipanggil oleh instruksi “SMC”. Ada fungsi dalam modul itu sendiri untuk mengimplementasikan panggilan SMC standar:kode yang mengimplementasikan antarmuka PSCI standar (dirancang untuk mengontrol seluruh platform, seperti mengaktifkan/menonaktifkan inti prosesor, manajemen daya di seluruh platform, dan reboot) dan juga menangani vendor -panggilan khusus (memberikan informasi tentang platform, mengelola perangkat yang disematkan, dll.).

Seperti disebutkan di atas, kehadiran modul BL3-2 adalah opsional; kodenya (dalam kasus modul) dieksekusi dalam mode EL1S. Biasanya, ini berfungsi sebagai layanan/monitor khusus untuk peristiwa yang terjadi selama operasi platform (interupsi dari penghitung waktu tertentu, perangkat, dll.)

Faktanya, BL3-3 bukan modul ATF, tetapi gambar firmware yang dijalankan dalam mode tidak aman. Biasanya mengambil kendali dalam mode EL2 dan mewakili gambar bootloader yang mirip dengan U-Boot yang dikenal luas atau lingkungan UEFI, yang merupakan standar untuk sistem server.

Bagan keseluruhan inisialisasi modul ATF ditunjukkan pada Gambar 2.

Gbr. 2. Inisialisasi modul ATF. (Sumber:Auriga)