Itu adalah terjemahan dari dua postingan yang diambil James Bottomley di blognya. Posting pertama dibuat pada 1 Februari dan disebut "LCA2013 dan Restrukturisasi Boot Aman"
Saya sudah lama tidak memberikan kabar, jadi sudah saatnya memberikan update tentang perkembangan Secure Boot Loader dari Linux Foundation (terutama karena sudah dipresentasikan di LCA2013). ( Link ke slide presentasi )
Inti masalahnya adalah GregKH (Greg Kroah-Hartman, seorang pengembang kernel) menemukan pada awal Desember bahwa Pre-BootLoader yang diusulkan tidak akan berfungsi dalam bentuknya saat ini dengan Gummiboot. Ini mengecewakan karena berarti tidak memenuhi misi Linux Foundation untuk mengaktifkan semua bootloader. Alasannya, setelah diselidiki, sederhana: Gummiboot dibuat untuk menunjukkan bahwa Anda dapat membuat bootloader kecil dan sederhana yang memanfaatkan semua layanan yang tersedia di platform UEFI, alih-alih menjadi link loader besar seperti GRUB. Sayangnya, ini berarti ia memboot kernel menggunakan fungsi BootServices->LoadImage(), yang berarti kernel yang akan di-boot harus melalui pemeriksaan boot aman di platform UEFI. Awalnya, Pre-BootLoader, seperti shim (bootloader Mathew Garrett), ditulis untuk menggunakan link loading PE/Coff untuk melewati pemeriksaan boot aman. Sayangnya, ini berarti bahwa apa pun yang dijalankan oleh Pre-BootLoader juga harus menggunakan link loading untuk mengatasi pemeriksaan secure boot pada apa pun yang ingin dimuatnya, dan oleh karena itu Gummiboot, yang sengaja bukan link loader, tidak akan berfungsi dalam skema ini.
Jadi saya harus merestrukturisasi dan menulis ulang: Masalahnya sekarang beralih dari "cara membuat pemuat tautan yang ditandatangani oleh Microsoft yang mematuhi kebijakan mereka" menjadi "cara mengaktifkan semua turunan pemuat boot untuk menggunakan fungsi BootServices-> LoadImage () cara untuk mematuhi kebijakan mereka. ' Untungnya, ada cara untuk mencegat infrastruktur penandatanganan platform UEFI dengan menginstal protokol keamanan arsitektur Anda sendiri. Sayangnya, spesifikasi inisialisasi platform sebenarnya bukan bagian dari spesifikasi UEFI, tetapi untungnya ini diterapkan oleh setiap sistem Windows 8 yang dapat Anda temukan. Arsitektur baru mencegat protokol itu dan menambahkan pemeriksaan keamanannya sendiri. Namun, ada masalah kedua: Saat kita berada dalam arsitektur panggilan kembali protokol keamanan, kita tidak selalu memiliki layar sistem UEFI, sehingga sangat tidak mungkin untuk melakukan pengujian pengguna untuk mengotorisasi eksekusi biner. Untungnya, ada cara non-interaktif untuk melakukan ini dan itu adalah mekanisme SUSE Machine Owner Key (MOK). Oleh karena itu, Pra-BootLoader Linux Foundation sekarang berevolusi untuk menggunakan variabel MOK standar untuk menyimpan hash biner resmi.
Hasil dari semua ini adalah Anda sekarang dapat menggunakan Pre-BootLoader dengan Gummiboot (seperti yang dilakukan dalam demo di LCA2013). Untuk mem-boot, Anda harus menambahkan 2 hash: satu untuk Gummiboot itu sendiri dan yang lainnya untuk kernel yang ingin Anda boot, tetapi sebenarnya itu hal yang baik karena sekarang Anda memiliki satu kebijakan keamanan yang mengontrol seluruh urutan boot. Gummiboot itu sendiri juga ditambal untuk mengenali kerusakan karena boot aman dan menampilkan pesan yang memberi tahu Anda hash mana yang harus didaftarkan.
Saya akan melakukan posting terpisah yang menjelaskan cara kerja arsitektur baru, tetapi saya pikir akan lebih baik untuk menjelaskan apa yang terjadi bulan lalu.
Dan posting kedua ini dia lakukan kemarin dan disebut "Meluncurkan Linux Foundation Secure Boot System"
Seperti yang dijanjikan, inilah Sistem Boot Aman Yayasan Linux. Itu sebenarnya dirilis kepada kami oleh Microsoft pada 6 Februari, tetapi dengan perjalanan, konferensi, dan pertemuan saya tidak punya waktu untuk memvalidasi semuanya sampai hari ini. File-file tersebut adalah:
Preloader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Buat juga image mini-USB yang dapat di-boot; (Anda harus menginstalnya di USB menggunakan dd; image memiliki partisi GPT, sehingga menggunakan seluruh disk). Ini memiliki shell EFI di mana kernel seharusnya dan menggunakan gummiboot untuk memuatnya. Anda bisa menemukannya di sini (md5sum 7971231d133e41dd667a184c255b599f).Untuk menggunakan image mini-USB, Anda harus memasukkan hashes untuk loader.efi (di folder \ EFI \ BOOT) dan shell.efi (di folder root). Ini juga termasuk salinan KeyTool.efi Anda harus memasukkan hash untuk menjalankan.
Apa yang terjadi dengan KeyTool.efi? Ini awalnya akan menjadi bagian dari kit yang kami tandatangani. Namun, selama pengujian, Microsoft menemukan bahwa karena bug di salah satu platform UEFI, itu dapat digunakan untuk menghapus kunci platform secara terprogram, yang akan merusak sistem keamanan UEFI. Sampai kami dapat menyelesaikan ini (kami memiliki vendor pribadi dalam loop), mereka menolak untuk menandatangani KeyTool.efi meskipun Anda dapat mengotorisasinya dengan menambahkan variabel MOK jika Anda ingin menjalankannya.
Beri tahu saya bagaimana ini berjalan karena saya tertarik untuk mengumpulkan umpan balik tentang apa yang berhasil dan apa yang tidak. Secara khusus, saya khawatir bahwa pengesampingan protokol keamanan tidak akan berfungsi pada beberapa platform, jadi saya secara khusus ingin tahu apakah itu tidak berfungsi untuk mereka.
Fuentes:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Putuskan apakah itu kabar baik atau buruk.