Get best of the week

Masalah dan fitur implementasi UEFI di berbagai platform

Sekitar sembilan belas tahun telah berlalu sejak dirilisnya spesifikasi EFI pertama pada tahun 2000. Butuh antarmuka sepuluh tahun untuk memasuki pasar pengguna dan mendapatkan pijakan di atasnya. Saat ini, jarang bisa Anda melihat komputer modern tanpa UEFI di firmware motherboard. Standar antarmuka telah meningkatkan "daging" dan beberapa ribu halaman dalam dokumentasi resmi. Untuk pengguna biasa, tidak ada yang berubah, kecuali untuk tabrakan sesekali dengan Boot Aman diaktifkan. Tetapi jika bidang pekerjaan bergeser ke pembangunan, semuanya menjadi lebih menarik.



Konsep arsitektur modular UEFI menyiratkan bahwa modul-modul ini tidak hanya dapat digunakan dalam konfigurasi standar, tetapi juga mengunduh sesuatu dari mereka sendiri. Driver sistem file (tidak terbatas pada FAT asli yang pemalu?), Driver Periferal, aplikasi, bootloader - Anda dapat memuat semuanya dengan tangan, alangkah baiknya memuat sedikit Shell. Anda dapat mengambil langkah "lebih dalam" dan melihat isi firmware, menyelamatkan diri Anda dari menari dengan SecureBoot dan kebutuhan untuk menulis lapisan skrip (ada cukup artikel di halaman hub).

Atas dasar ini, lahirlah ide untuk menciptakan modul fungsional yang melakukan berbagai fungsi keamanan sebelum memuat OS, yang nantinya dapat menggabungkan dan menjadi sesuatu seperti lingkungan boot tepercaya terintegrasi yang memengaruhi kedua layanan antarmuka boot dan runtime sedemikian rupa sehingga antara modul dalam firmware dan modul pada disk tidak ada yang bisa "didorong" tanpa intervensi tingkat rendah, dan setelah mereka - hanya dengan izin dari administrator keamanan.

Implementasi dari ide ini memperkenalkan kami pada sejumlah besar nuansa dan kehalusan UEFI - dimulai dengan banyak fitur, bug, dan tidak terdokumentasi dengan buruk, dan diakhiri dengan perilaku tidak terdefinisi yang sangat disukai oleh semua pengembang. Mari kita mulai.

Ketergantungan Platform




Hal pertama yang perlu Anda ketahui ketika berintegrasi ke dalam platform adalah apakah kami dapat bekerja dengannya? Versi spesifikasi UEFI adalah penting, dan pada sebagian besar perangkat disajikan dalam kisaran antara 2.1 dan 2.7. Yang lebih baru belum menyentuh stand penelitian. Yang lebih tua ditemukan, dan kinerjanya mungkin terbatas karena kurangnya protokol yang diperlukan atau driver yang ditulis miring untuk implementasi mereka. Misalnya, UnicodeCollation sering tidak cukup, ketika mengakses smbios ada kesalahan tidak berdokumen, fungsi perubahan bahasa melalui SetVariable () tidak berfungsi. Apa pun bisa terjadi, tergantung pada vendor dan kesegaran, karena kadang-kadang Anda harus meletakkan protokol Anda bahkan di papan yang relatif baru.

Bahkan dalam praktik kami, saya cukup beruntung menemukan dua komputer mini dengan Intel Bay Trail D dan firmware 32-bit. Kasing ini jarang, tetapi pada suatu waktu membuatnya perlu untuk mengkompilasi ulang modul. Sebenarnya, seperti pertanyaan: apakah kita akan bertemu dengan platform yang lebih modern dengan kapasitas yang sama di masa depan? Dan jika kita bertemu, lalu di mana?

Langkah selanjutnya adalah menentukan cara mengintegrasikan. Modul-modul dibangun ke dalam firmware, firmware terletak di chip SPI di papan, dan PCH dengan Intel ME terletak di dekatnya. Dan di sini muncul pertanyaan yang paling menarik - bagaimana menuju ke sana? Pemrogram tua yang baik dengan "buaya" - ini bagus, dapat diandalkan. Bahkan jika Anda tidak memahami sampai akhir, Anda selalu dapat melihat LED menyala di papan, mereka memiliki kekuatan yang cukup dari programmer. Ini bekerja hampir tanpa cacat, dengan pengecualian pada beberapa model HP yang lebih lama, di mana mikruha SOIC-16 dengan firmware sangat mudah diakses sehingga lebih mudah untuk membuat dan menyolder adaptor ke kakinya daripada menekan klipnya.



Saya tahu bahwa ada orang-orang di Habré yang telah berkontribusi dalam penulisan flashrom, terima kasih kepada mereka secara terpisah.

Tetapi, terlepas dari keandalan dan keandalan pembuangan limbah oleh programmer, metode ini tidak cocok jika Anda perlu menginstal sesuatu di UEFI pada beberapa mesin, atau jika platform target untuk pemasangan tidak ada di meja Anda. Untungnya bagi kami, produsen meninggalkan utilitas firmware asli: FPT (alat pemrograman Flash) dari kit Alat Sistem ME Intel (CS), dan AFU (Pembaruan Firmware AMI) untuk Aptio dari American Megatrends. Utilitas ini diluncurkan baik dari lingkungan EFI dan dari sistem operasi Windows, Linux, dan DOS. Utilitasnya agak dapat dipertukarkan, keduanya memungkinkan Anda untuk mempertimbangkan gambar, jika tidak keseluruhan, maka wilayah tertentu pasti. Dan kadang-kadang mereka bahkan membiarkan Anda menulis kembali.



Dia menulis dan tidak menulis

Di sinilah batu sandungan serius pertama di jalur integrasi muncul. Tidak semua motherboard memungkinkan Anda membaca seluruh firmware, melarang akses ke wilayah ME (ME hampir sakral, Intel tidak akan mengizinkannya dibaca dengan cara yang baik, tetapi dengan cara yang buruk kami tidak selalu ingin). Bahkan kurang - tuangkan sesuatu bahkan ke wilayah BIOS, kecuali jika itu adalah kapsul yang ditandatangani. Kemungkinan sukses sangat bervariasi tergantung pada produsen dan kesegaran chipset. Pada beberapa model motherboard, Anda dapat mengamati gambar lucu: apa yang tidak direkam pada papan vendor lama, terbang pada zaman baru.

Terkadang parser IFR membantu melawan perlindungan penulisan, yang membuka tirai pada pengaturan dan variabel tersembunyi. Dan terkadang hanya pelompat hardcore yang membantu, memungkinkan akses ke rekaman atau "mematikan" ME (jika ada, tentu saja).

Sifat kompleks dari sistem


Papan Acer, Asus, AsRock, dan Gigabyte dalam banyak kasus ditulis tanpa kesulitan yang tidak perlu. Intel, HP, dan perangkat keras server terpisah. HP tidak hanya tidak mengizinkan penulisan itu sendiri secara terprogram, tetapi juga bersumpah atas segala upaya untuk memodifikasi firmware (dalamCodeRush ada artikel tentang menemukan dan menonaktifkan pemeriksaan integritas). Intel kurang lebih mencatat hingga chipset ke-87, kemudian menjadi tuli terhadap permintaan untuk membuka gerbang wilayah BIOS.

Dengan Intel, pertama kali lucu. Modul-modul tersebut diimpor ke dalam firmware menggunakan UEFITool utility, dan kami menemukan bug yang menarik: jika Anda memasukkan modul ffs di akhir volume DXE, setelah semua bentuk bebas, maka gambar yang dirangkai "mengacaukan" papan. Solusinya adalah menambahkan modul setelah driver DXE asli. Kami tidak segera melakukan ini, dan pada awalnya kelihatannya Intel sedang memantau integritas firmware, seperti HP. Kemudian menjadi jelas bahwa seseorang tidak dapat melakukannya tanpa utilitas otomatis untuk mengimpor modul, dan masalahnya menjadi sia-sia setelah menulisnya.

Perangkat keras sisi server lebih sederhana dan lebih kompleks pada saat bersamaan. Di satu sisi, selalu ada cara tambahan untuk memperbarui dan memodifikasi BIOS di server, di sisi lain, volume penyesuaian di BIOS yang sama ini sangat luar biasa, karena mereka tidak berhemat pada server dan memasang chip memori flash yang cukup luas, sering kali juga mendukungnya.

Saat memasang di server, selalu menyenangkan untuk dapat memperbarui BIOS dari jarak jauh melalui IPMI. Benar, untuk ini dengan cara yang baik Anda memerlukan lisensi, tentu saja dibayar. Jika itu tidak muncul pada waktu yang tepat, sangat mungkin untuk masuk ke situasi lucu yang sama dengan yang kita dapatkan dengan memperkenalkan modul ke dalam server BIOS Supermicro.

Setelah pengenalan modul, beban membeku karena blok oleh salah satu modul keamanan (mereka tidak memperhitungkan ketidakpatuhan dari BIOS server, dengan siapa itu tidak terjadi!). Dengan tidak adanya kemampuan untuk memaksa BIOS untuk meluncur kembali melalui IPMI, tangan itu sendiri meraih programmer, tetapi itu adalah nasib buruk - klip SOIC-8 standar tidak cukup untuk chip SOIC-16! Baiklah, oke, karena secara teori papan server memiliki kemampuan untuk membuat cadangan dari media yang terhubung, mengambil gambar SUPER.ROM di root. Tetapi mekanisme ini tidak dimulai, karena menurut sistem semuanya OK, semuanya berfungsi, oleh karena itu, kembalikan BIOS tidak diperlukan! Apa yang harus dilakukan ?! .. Kisah itu akhirnya berkeliaran di kota untuk mencari klip yang tepat, penyolderan kembali kabel secara darurat, diolesi oleh Cina dengan urutan yang tidak dapat dipahami oleh kita, dan akhirnya - kilatan.

Lenovo keluar bahkan lebih menarik. Pada sakelar yang diterima dari vendor, di bawah penutup kasing, sebuah papan kontrol ditemukan dengan dua "mikruh" untuk firmware, dengan SSD untuk OS dan dengan baterai tetap. BIOS ternyata sangat sulit, saya tidak ingin memakan gambar yang dimodifikasi dengan cara apa pun, hanya menyerah pada programmer. Dalam salah satu upaya untuk menulis sesuatu, mereka memasukkan flash drive dengan konsol ubuntu ke sakelar (terminal tidak memberikan gambar) dan boot dengan cukup aman. Setelah melakukan apa yang diperlukan, mereka mematikan sistem menggunakan perintah berhenti -p dari memori lama. Switch, pada dasarnya tidak disesuaikan untuk shutdown apa pun, kecuali kurangnya daya, tidak siap untuk ini dan tidak ingin memulai lagi. Tautan pada wajah terbakar sekali, kipas berdesir pelan, dan semua port tidak memberikan apa-apa. Berkedip ulang tidak membantu,baterai duduk seperti sarung tangan - kami takut mematahkan dudukan. Akibatnya, pelat dielektrik tipis merangkak di bawah kekuatan ketekunan dan inspirasi verbal di bawah kontak, ingatan yang mudah menguap terhapus, pergantian menjadi hidup kembali.

Studi tentang dump yang diambil dari dua chip menunjukkan banyak hal menarik. Secara khusus, sejumlah besar entri "Tidak Valid" di NVRAM dari firmware utama dan beberapa yang serupa di cadangan. Nah, dan bukan hash data yang sebelumnya ditemui dalam volume dengan driver DXE. Orang hanya bisa menebak tentang penyebab pasti dari memulai sakelar.

Secara umum, bagian perangkat lunak jarang kehilangan nuansa yang tidak terduga. Banyak motherboard yang datang kepada kami sebelum chipset ke-87 (dari produsen yang berbeda) memiliki fitur yang tidak menyenangkan untuk menghasilkan aliran kesalahan yang tak ada habisnya ketika memasukkan perintah "dh -v" di konsol shell. Dengan entri manual, ini tidak penting, tetapi ketika mengumpulkan data ke dalam file, itu berakhir dengan hang yang tidak menguntungkan. Dalam kedua kasus, Anda harus me-restart mesin. Saya senang bahwa pada saat yang sama file data tidak membengkak ke ukuran yang sangat besar.



Kraftway BIOS dengan papan ASRock H81M-DGS terbukti sangat bandel. Jadi, ini merespon Ctrl Alt Del Del dengan cara menggantung, dari yang hanya Reset dapat menampilkannya. Ada masalah dengan melewatkan skrip startup <startup.nsh> di Shell'e - sepersekian detik untuk dipilih daripada lima yang default. Mungkin masalah ini disebabkan oleh modifikasi oleh modul kepemilikan KSS, mungkin masalah ini tidak akurat "tidak berkunci" ME.

Pada papan Asus H97-PLUS, firmware memiliki fitur berikut - BootOrder meluap seiring waktu. Kemungkinan besar, alasannya terletak pada kesalahan dalam kode. Meskipun, mungkin, pabrikan ingin menyimpan semua perangkat boot yang pernah terhubung di papan, tetapi tidak menghitung bahwa mungkin ada lebih dari selusin dalam satu hari. Jadi, ketika BootOrder meluap, sistem hang selama proses boot. Untuk membersihkannya, Anda harus mematikan semua perangkat boot dan menyalakan sistem. Firmware akan hilang dengan sendirinya dan sistem melakukan boot langsung ke shell BIOS Setup. Performa tetap sampai meluap berikutnya.

Merangkum pengalaman bekerja dengan dewan berbagai vendor, Anda sampai pada kesimpulan bahwa hampir tidak mungkin untuk mengetahui kejutan apa pada tingkat EFI yang akan Anda hadapi di papan berikutnya, bahkan jika sudah memiliki model yang terkenal. Ini adalah semacam lotere, karena kadang-kadang kesulitan mungkin timbul pada tahap pengumpulan informasi tentang sistem. Mungkin ini memiliki bagian dari idealisme penelitian yang tidak terpadamkan dan kepercayaan pada pabrikan, karena bagaimana lagi beberapa motherboard terbaru dengan ME v11 dan v12 dapat bertahan ketika menjalankan FPT atau MEInfo versi lama pada mereka?

Masalah bekerja dengan protokol perangkat keras




Beberapa masalah muncul ketika kita mulai bekerja dengan perangkat USB - drive dan token. Ini sering terjadi karena kode BIOS untuk bekerja dengan periferal adalah campuran berbahaya driver dan aplikasi dari Independent Hardware Vendor (IHV) untuk periferal tertentu, kode dari produsen chipset (dalam kasus kami, dari Intel), kode dari produsen dan kode BIOS dari produsen motherboard.

Situasi "menarik" berikut

muncul : Tanda "tidak terdeteksi". Pada saat yang sama, LED menyala di atasnya. Kemungkinan besar, pengontrol host tidak melalui prosedur reset awal perangkat USB, yaitu, daya diberikan, tetapi reset melalui perubahan D + dan garis D tidak bekerja dengan benar, dan tanpa itu manipulasi lebih lanjut dengan token tidak ada artinya.

Komputer macet sebelum memuat shell (sekali lagi, dengan token terhubung). Dalam hal ini, tanpa token, PC mulai normal. Langsung, tampilannya seperti ini: komputer tampaknya macet tepat setelah start, sedangkan token menonjol pada konektor. Anda mengeluarkannya - memuat tiba-tiba berlanjut. Hubungkan - menggantung lagi. Masalah yang jelas ada di UEFI, dan orang hanya bisa berspekulasi tentang alasannya.

Situasi ketika tidak mungkin untuk membuka antarmuka USB_IO. Mungkin itu terhubung hanya dengan antarmuka untuk bekerja dengan kartu pintar - USB CCID. Beberapa driver AMI telah membuka USB_IO dengan parameter EFI_OPEN_PROTOCOL_BY_DRIVER. Pengemudi memiliki protokol dengan GUID:

#define EFI_AMI_USB_CCID_PROTOCOL_GUID	 { 0x5FDEE00D, 0xDA40, 0x405A, { 0xB9, 0x2E, 0xCF, 0x4A, 0x80, 0xEA, 0x8F, 0x76} }
 // Workaround.      EFI_OPEN_PROTOCOL_BY_DRIVER,  ,     EFI_OPEN_PROTOCOL_GET_PROTOCOL.
 //
 // Open USB I/O Protocol
 //
 Status = gBS->OpenProtocol (
 ControllerHandle,
 &gEfiUsbIoProtocolGuid,
 (VOID **) &UsbIo,
 This->DriverBindingHandle,
 ControllerHandle,
 EFI_OPEN_PROTOCOL_BY_DRIVER
 );

 if (EFI_ACCESS_DENIED == Status)
 {		// AMI BIOS workaround (BindingStop will not be invoked)
	 Status = gBS->OpenProtocol(
		 ControllerHandle,
		 &gEfiUsbIoProtocolGuid,
		 (VOID **)&UsbIo,
		 This->DriverBindingHandle,
		 ControllerHandle,
		 EFI_OPEN_PROTOCOL_GET_PROTOCOL
	 );
 }

Namun, BindingStop () tidak akan dipanggil, mis. acara ekstraksi perangkat tidak dipantau, dan driver akan mencoba menggunakan pegangan yang tidak valid. Ini diamati dengan PC HP Compaq Elite 8300 SFF dan beberapa lainnya. Ini adalah semacam perlindungan vendor dari driver yang tidak diinginkan, atau bug pengembangan reguler. Mungkin AMI terus melakukan sesuatu ke arah USB CCID, tetapi driver yang mengganggu tidak dapat diturunkan, karena terletak di modul AMI UHCI yang sama bersama dengan USB HID, USB MassStorage. Dengan UninstallInterface (), semuanya serupa.

Atau fitur menarik lainnya. Di salah satu UEFI BIOS, di mana token tidak terdeteksi, USB_IO diizinkan membaca deskriptor perangkat, tetapi EFI_INVALID_PARAMETER kembali ke UsbBulkTransfer berikutnya (). Selain itu, ini hanya terjadi pada beberapa jenis token, dengan parameter yang benar-benar sama, yang lain bekerja dengan sempurna.

Secara umum, protokol UsbBulkTransfer () secara menarik diimplementasikan dalam protokol EFI_USB_IO_PROTOCOL. Ini dimaksudkan untuk pengiriman paket yang dijamin untuk waktu yang tidak terbatas, atau untuk waktu yang ditentukan dalam parameter Timeout. Tetapi percobaan dilakukan dengan perangkat MassStorage: ketika menyalin file besar ke USB flash drive, itu dihapus. PC hang ketat. Saat menghubungkan USB flash drive, PC melorot dan terus menulis file seolah-olah tidak ada yang terjadi. Situasi yang sama adalah dengan token, tetapi dengan spesifiknya sendiri. Ini adalah masalah arsitektur, di EFI tidak ada gangguan kecuali penghitung waktu, dan perangkat beroperasi sesuai dengan jajak pendapat. Artinya, sistem crash di suatu tempat di jajak pendapat USB, tetapi tidak mencapai batas waktu, ketika perangkat muncul kembali, itu hanya melanjutkan dan menyelesaikan operasi.

Virtualisasi


Kami juga harus mengatakan tentang lingkungan virtual. Saat ini ada dua platform utama di pasar yang mendukung persaingan lingkungan EFI: VMware dan VirtualBox. Keduanya memiliki kelebihan dan kekurangan ketika berinteraksi dengan mereka seperti dengan sistem "nyata". Lingkungan VMware secara memadai menyediakan pekerjaan dengan variabel NVRAM, tetapi tersandung ketika menampilkan pesan secara visual selama inisialisasi modul DXE: dalam kasus terbaik, preferensi akan diberikan pada pesan asli tentang menemukan media yang dapat di-boot, meninggalkan apa yang kita butuhkan. VirtualBox, sebaliknya, secara sempurna merender semua yang diperlukan, tetapi tidak ingin mengingat variabel yang panjang.

Batu kecil lain di taman VMware - driver FAT32 yang dibangun di dalamnya mendukung pembuatan dan pengeditan file hanya dalam notasi 8.3. Tidak jelas mengapa ini dilakukan, tetapi ini adalah batasan yang jelas membutuhkan perhatian. Kemungkinan implementasi serupa dari driver dapat diamati pada platform nyata, tetapi sejauh ini kami belum menemukan itu.

Di sisi lain, di mesin virtual tidak ada tarian dengan utilitas firmware, programmer, jumper, chip yang tidak nyaman. File ROM terpisah, UEFITool dan satu baris dalam file konfigurasi. Hampir idilis.

Pada akhirnya



Sepotong permintaan dari CHIPSEC. Di mana mereka mengajarkan sakramen seperti itu?

Seperti yang telah disebutkan, pengembangan dan implementasi di shell UEFI adalah proses yang menarik dan kreatif. Anda selalu dapat menemukan sesuatu yang baru bahkan di bidang yang terkenal. Di satu sisi, ini mendorong bahwa standar berkembang, di sisi lain, menyedihkan bahwa implementasi konkret dari itu oleh produsen terlalu "kreatif".

Masalah utama adalah dan tetap:

  1. Keberangkatan vendor dari spesifikasi UEFI saat mengembangkan firmware.
  2. Kesalahan dalam kode selama implementasi.
  3. Kode NDV, muncul selama integrasi.

Dan yang terakhir, namun tidak kalah pentingnya, tidak adanya banyak hal dalam dokumentasi resmi (baca, buka), seperti, misalnya, uraian protokol untuk berkomunikasi dengan ME melalui perangkat PCI seperti MEI, HECI. Anda dapat menemukan deskripsi register, tetapi bukan perintahnya. Temukan GUID, tetapi bukan tujuannya. Yang sekali lagi mengembalikan pekerjaan ke analisis panjang, mengumpulkan data dan statistik pada platform dan menggunakan disassembler.

Perlu dicatat bahwa situasinya lambat tapi pasti sedang diperbaiki, dan saya ingin percaya bahwa saat ini tidak jauh ketika pengembangan standar akan menjadi proses yang cukup dapat diprediksi dan sangat menyenangkan.

Vladimir Onipchuk,
Kepala kelompok produk perlindungan perangkat keras dan perangkat lunak
Gazinformservice LLC

More articles:


All Articles