Bagikan melalui


Pengurangan Permukaan Serangan Firmware (FASR)

Pada Bulan Oktober 2019, Microsoft bekerja sama dengan mitra OEM dan Silicon kami untuk meluncurkan PC Secured-core. Perangkat ini memiliki perangkat keras, firmware, dan perangkat lunak yang terintegrasi secara mendalam untuk membantu memastikan keamanan yang ditingkatkan untuk perangkat, identitas, dan data. Salah satu pilar keamanan inti PC Secured-core adalah membantu menawarkan perlindungan firmware untuk perangkat. Fitur berbasis perangkat keras mendasar yang diperlukan untuk memenuhi pilar ini adalah Dynamic Root of Trust for Measurement (D-RTM). Namun, tidak banyak perangkat yang menawarkan D-RTM saat ini karena ketergantungan pada chipset yang mendasar untuk mendukung kemampuan ini, yang menghambat komitmen kami untuk membantu meningkatkan dan menjunjung tinggi bilah keamanan untuk semua perangkat Windows.

Lebih banyak dapat dilakukan untuk meningkatkan postur keamanan semua perangkat Windows, termasuk ini tanpa D-RTM. Microsoft bekerja sama dengan mitra untuk mengatasi masalah kompatibilitas yang mencegah perlindungan memori diterapkan di firmware UEFI dengan mengembangkan serangkaian penyempurnaan keamanan SMM sumber terbuka untuk memberikan fleksibilitas tambahan bagi OEM untuk digunakan.

Untuk mencerminkan komitmen ini terhadap keamanan firmware, kami telah mengidentifikasi pendekatan baru untuk memastikan bahwa perangkat dapat memenuhi persyaratan perlindungan firmware PC Secured-core.

Gambaran umum FASR

Untuk PC Secured-core yang tidak memiliki kemampuan D-RTM berbasis perangkat keras, kita harus menentukan sekumpulan kecil komponen firmware yang menyajikan permukaan serangan yang berkurang dan dapat dibuktikan dalam sistem operasi. Pendekatan ini disebut Firmware Attack Surface Reduction (FASR). Agar firmware berbasis FASR menskalakan di seluruh PC dari vendor yang berbeda, pendekatan baru untuk proses boot firmware harus ditentukan.

FASR mendukung dua jalur boot:

  1. Jalur boot bersertifikat:

    • Hanya kode tepercaya, ditandatangani, dan diintegrasikan oleh Microsoft yang diizinkan untuk dijalankan.

    • Perubahan jalur boot dapat dideteksi oleh sistem operasi.

    Gambar di bawah ini menunjukkan alur boot FASR S-RTM pada jalur boot bersertifikat. Jalur boot ini membantu mencegah kode firmware platform yang tidak terduga dijalankan. Namun, itu memang menggunakan beberapa data khusus platform yang disediakan oleh jalur boot kustom. Diagram berikut menunjukkan alur boot FASR pada jalur boot bersertifikat.

    Alur boot F A S R pada jalur boot bersertifikat

  2. Jalur boot kustom: Semua kode firmware platform dapat dijalankan. Informasi boot-critical khusus untuk OEM/platform tertentu dikonversi menjadi data pada jalur boot kustom dan digunakan oleh jalur boot bersertifikat untuk mengonfigurasi sistem dengan benar pada jalur boot tersebut. Diagram berikut menunjukkan alur boot FASR pada jalur boot kustom.

    Alur boot F A S R pada jalur boot kustom

    Perangkat FASR yang diaktifkan untuk kepatuhan PC Secured-core, default ke jalur boot bersertifikat kecuali terjadi peristiwa yang menyebabkan boot beralih ke jalur boot kustom di awal proses boot firmware. Contoh peristiwa tersebut termasuk pembaruan firmware, pengguna meminta UI firmware, atau pengguna telah memilih untuk menonaktifkan PC Secured-core yang berarti mereka akan selalu boot pada jalur boot kustom hingga dapat diaktifkan kembali.

    Boot kustom dapat digunakan untuk mem-boot sistem operasi atau perangkat lunak pihak ketiga apa pun seperti yang didukung oleh firmware platform pada perangkat berkemampuan FASR, tetapi Windows tidak akan mengenali boot pada jalur boot kustom sebagai sesuai dengan PC Secured-core.

Untuk lebih memahami teknologi keamanan di balik FASR, kami ingin berbagi gambaran umum singkat tentang proses boot Windows.

Proses boot Windows

Akar kepercayaan

Eksekusi firmware awal dalam PC modern mengikuti proses boot di mana sekumpulan kode awal memuat kode lain, dan tingkat fungsionalitas meluas saat boot berlangsung. Setiap set kode memverifikasi serangkaian kode berikutnya yang membentuk rantai kepercayaan. Ketika firmware UEFI mendapatkan kontrol, firmware UEFI mengikuti standar Boot Aman untuk memverifikasi tanda tangan perangkat lunak untuk melanjutkan rantai kepercayaan hingga ke sistem operasi. Kemudian, pemuat boot Windows melanjutkan rantai kepercayaan dengan Boot Tepercaya, yang memverifikasi setiap komponen OS lainnya dalam proses startup sebelum dimuat.

Secara umum, penyerang berusaha untuk mendapatkan kontrol sedini mungkin dalam proses boot sebelum fitur keamanan dan kunci yang membantu melindungi sistem diaktifkan. Ketika sistem dibawa keluar dari reset, kumpulan kode awal yang dijalankan harus berlabuh dalam kepercayaan. Teknologi verifikasi perangkat keras yang memenuhi peran untuk melakukan verifikasi kode awal ini disebut akar kepercayaan. Meskipun detail yang tepat bervariasi menurut vendor perangkat keras, semua akar kepercayaan biasanya berakar pada perangkat keras atau ROM yang tidak dapat diubah di SOC.

Boot terukur

Boot Aman berlabuh dalam akar kepercayaan membantu memastikan bahwa tanda tangan digital semua firmware diverifikasi; namun, juga diinginkan untuk memiliki catatan tentang firmware apa yang dijalankan. Program Kompatibilitas Perangkat Keras Windows mengharuskan semua PC Windows 10 dan Windows 11 menyertakan chip yang disebut Modul Platform Tepercaya (TPM). TPM berisi lokasi memori yang disebut Platform Configuration Registers (PCR). Setiap PCR berisi hash untuk jenis kode dan/atau data yang dimuat selama boot seperti kode firmware pada perangkat penyimpanan nonvolatile (misalnya, flash SPI), opsi ROM dari perangkat PCI, atau pemuat boot OS. Ukuran nilai yang dapat disimpan dalam PCR ditentukan oleh ukuran hash algoritma hashing yang didukung. Misalnya, SHA-1 PCR dapat menyimpan 20 byte sementara SHA-2 PCR dapat menyimpan 32 byte. Beberapa PCR yang terkait dengan algoritma hashing yang sama disebut bank. Spesifikasi Profil TPM Klien TCG PC mendefinisikan penyertaan setidaknya satu bank PCR dengan 24 register.

Dengan adanya TPM, setiap komponen firmware juga dapat memperbarui atau memperluas PCR yang sesuai karena kode dan data baru dimuat dalam proses boot. Proses perluas memperbarui nilai PCR menjadi output dari algoritma hash menggunakan nilai PCR saat ini yang digabungkan dengan kode baru atau argumen data sebagai input. Hasilnya adalah PCR dapat diperiksa setelah proses boot untuk menentukan apa yang dijalankan. Ini memungkinkan perangkat lunak dalam sistem operasi untuk memahami apakah proses boot berbeda dari boot sebelumnya. Dalam lingkungan sensitif keamanan, sistem operasi dapat diberi tahu tentang serangkaian pengukuran kode yang tepat yang diharapkan dalam PCR tertentu untuk mendeteksi eksekusi kode firmware yang tidak terduga. Karena 16 PCR pertama di bank hanya dapat diatur ulang dengan mengatur ulang seluruh TPM, pcr tepercaya, dan lokasi pilihan untuk menyimpan pengukuran penting dalam TPM.

Akar kepercayaan untuk pengukuran

Sekarang setelah kita memeriksa peran akar kepercayaan dan bagaimana Boot Terukur digunakan, kita akan melihat dua pendekatan umum untuk membangun akar kepercayaan untuk melaporkan rantai pengukuran ke TPM: statis dan dinamis.

Akar Kepercayaan Statis untuk Pengukuran (S-RTM) menetapkan kepercayaan pada reset sistem dan mengharuskan kepercayaan tersebut dipertahankan di seluruh proses boot. Jika kepercayaan disusupi kapan saja dalam proses boot, kepercayaan tidak dapat dipulihkan sampai sistem direset. Diagram berikut menggambarkan bagaimana S-RTM digunakan pada jalur boot bersertifikat.

akar pengukuran kepercayaan statis

Sebaliknya, Dynamic Root of Trust for Measurement (D-RTM) hanya mempercayai sebagian kecil dari kode firmware inisialisasi chipset awal, dan agen perangkat keras yang digunakan untuk membangun kembali kepercayaan secara dinamis selama boot. Sistem awalnya dapat melakukan boot ke kode firmware yang tidak tepercaya tetapi—tak lama setelah peluncuran—kembali ke keadaan tepercaya dengan mengambil kendali atas semua CPU dan memaksa mereka turun ke jalur yang terkenal dan terukur. Diagram berikut memberikan gambaran umum tentang alur D-RTM tradisional.

akar pengukuran kepercayaan dinamis

Ada tradeoff antara S-RTM dan D-RTM. S-RTM tidak memerlukan kemampuan perangkat keras khusus tetapi memerlukan perangkat lunak untuk memperhitungkan kode yang dijalankan selama seluruh boot. D-RTM memerlukan kemampuan perangkat keras khusus tetapi memungkinkan perangkat lunak untuk diluncurkan ke status tepercaya secara dinamis selama masa pakai sistem.

PC Windows Secured-core telah menggunakan D-RTM dalam Peluncuran Aman untuk memungkinkan fleksibilitas bagi serangkaian produsen sistem yang luas untuk menerapkan fitur dan pengalaman unik di firmware sekaligus membantu memastikan sistem dapat mencapai status tepercaya dan terukur yang dapat diterima untuk menghosting lingkungan sistem operasi yang aman. Peristiwa peluncuran D-RTM digunakan untuk membangun kembali kepercayaan dari lingkungan yang tidak diketahui sebelum memuat kernel yang aman. Diagram berikut menunjukkan peristiwa peluncuran D-RTM untuk membangun kembali lingkungan sistem yang diketahui.

Peristiwa peluncuran D R T M untuk membangun kembali lingkungan sistem yang diketahui

Di masa lalu, S-RTM dapat diimplementasikan di lebih banyak perangkat karena kurangnya dependensi pada kemampuan perangkat keras khusus untuk memverifikasi status keamanan sistem, tetapi sistem operasi tidak memiliki metode yang dapat diandalkan untuk mengonfirmasinya dapat mempercayai pengukuran yang dilaporkan pada perangkat Windows tertentu menggunakan S-RTM.

Peningkatan keamanan firmware

Meminimalkan komponen firmware di jalur boot OS

Salah satu cara untuk mempercayai pengukuran S-RTM adalah dengan mengurangi komponen firmware yang diizinkan untuk dijalankan ke set minimal. Jika semua perangkat yang menggunakan S-RTM menggunakan sekumpulan komponen firmware yang sama, sistem operasi hanya perlu mempercayai satu set nilai PCR yang diharapkan untuk komponen yang diketahui dan tepercaya. Dengan pendekatan berbasis SRTM ini, perangkat dapat dianggap telah memenuhi persyaratan perlindungan firmware PC Inti Aman ketika kumpulan firmware boot diverifikasi hanya berisi perangkat lunak bertanda tangan Microsoft yang dapat dibuktikan oleh Windows. Untuk lebih memahami bagaimana komponen firmware ini berbeda dengan yang ada di boot PC normal, mari kita periksa proses boot sebelum dan sesudahnya.

Karena fleksibilitas dan serangkaian fitur kaya yang ditawarkan oleh firmware PC modern, kode yang dijalankan sebelum sistem operasi menghasilkan peningkatan permukaan serangan. Diagram berikut menunjukkan contoh alur boot S-RTM tradisional.

alur boot S R T M tradisional

Tanggung jawab utama firmware selama boot dapat sangat disederhanakan untuk:

  • Khusus platform: Fungsionalitas yang hanya berlaku untuk desain perangkat keras platform tertentu.

  • Khusus non-platform: Fungsionalitas yang standar industri dan umum untuk perangkat keras lainnya.

Subset firmware modern yang relatif kecil biasanya spesifik platform. Sebagian besar kode infrastruktur firmware yang melakukan tugas umum seperti mengalokasikan memori, mengirimkan driver firmware, menangani peristiwa, dan sebagainya, sama antara semua (atau sebagian besar) sistem berbasis UEFI. Driver biner firmware untuk tugas-tugas ini dapat digunakan kembali di seluruh PC. Selain itu, spesifikasi dan antarmuka perangkat keras standar industri memungkinkan driver firmware umum untuk menginisialisasi hard disk, pengontrol USB, dan periferal lainnya. Driver biner firmware untuk perangkat keras ini juga dapat digunakan kembali di seluruh PC. Singkatnya, PC dapat di-boot dengan sekumpulan driver firmware umum minimal.

Mengurangi total set driver firmware yang dimuat selama boot dapat menyebabkan keuntungan lain:

  • Waktu boot yang ditingkatkan

  • Koordinasi vendor yang lebih sedikit untuk pembaruan

  • Pengurangan paparan bug

  • Pengurangan permukaan serangan

Verifikasi jalur boot FASR dan kepatuhan inti aman

Agar sistem FASR memenuhi persyaratan perlindungan firmware PC Secured-core, ia harus melakukan boot pada jalur boot bersertifikat. Firmware FASR memfasilitasi ini dengan menyediakan sistem operasi dengan manifes yang ditandatangani Microsoft yang disebut manifes FASR (diukur ke dalam TPM) yang berisi nilai PCR yang diharapkan untuk urutan boot modul pada jalur bersertifikat. Ini dapat dibandingkan dengan urutan boot aktual yang terjadi pada jalur bersertifikat. Jika pengukuran ini cocok, sistem dianggap telah memenuhi persyaratan perlindungan firmware dari program PC Secured-core. Setiap penyimpangan dari urutan jalur boot bersertifikat yang diharapkan menghasilkan pengukuran tak terduga yang dilakukan ke dalam Daftar Konfigurasi Platform (PCR) TPM yang dideteksi sistem operasi.

Selain itu, Windows hanya akan merilis rahasia yang dilindungi hypervisor setelah validasi manifes FASR yang ditandatangani berhasil terhadap pengukuran yang dicatat selama boot saat ini. Jika pada jalur boot bersertifikat atau pembaruan kapsul, manifes FASR tidak ada, verifikasi tanda tangan gagal atau ketidakcocokan PCR terjadi, dan rahasia VSM tidak akan disegel atau dimigrasikan.

Bagaimana firmware FASR mengatasi perlindungan memori dan SMM

Sekarang setelah satu biner yang ditandatangani Microsoft dengan serangkaian fungsionalitas minimal telah ditentukan, itu dapat mencakup perlindungan keamanan firmware mendasar tetapi hilang, Microsoft bekerja sama dengan mitra untuk dibawa ke pasar. Jalur boot bersertifikat harus minimal memenuhi persyaratan berikut:

  1. Kode tidak membaca/menulis ke NULL/Halaman 0

  2. Kode gambar dan bagian data dipisahkan

  3. Bagian gambar diratakan pada batas halaman (4 KB)

  4. Data hanya dialokasikan ke dalam jenis memori data dan kode ke dalam jenis memori kode

  5. Gambar kode tidak dimuat dari kode yang didistribusikan sebagai biner UEFI (hanya dispatcher yang ditunjuk)

  6. Kode tetap berada dalam batas buffer memori yang dialokasikan dengan halaman penjaga di sekitar alokasi halaman

  7. Luapan tumpukan dapat dideteksi

  8. Kode tidak dijalankan dari tumpukan

  9. Karakteristik DLL /NXCOMPAT diatur untuk mengaktifkan perlindungan NX

RoM opsi pihak ketiga, aplikasi UEFI, dan driver UEFI sering kali tidak dibangun atau divalidasi terhadap serangkaian persyaratan ini. Oleh karena itu, mereka tidak akan mengeksekusi pada jalur boot bersertifikat. Jalur boot kustom dapat secara opsional memilih untuk menurunkan tingkat perlindungan yang diperlukan, tetapi jalur boot tersebut tidak dianggap sesuai dengan PC Inti Aman oleh sistem operasi.

Mode Manajemen Sistem (SMM)

SMM adalah mode operasi prosesor khusus dalam arsitektur x86. Ini menghadirkan tantangan unik untuk keamanan sistem karena kode yang dijalankan di lingkungan SMM buram untuk sistem operasi dan biasanya dijalankan pada tingkat hak istimewa tertinggi (kadang-kadang disebut sebagai "Cincin -2") dari perangkat lunak apa pun pada prosesor host. Setelah masuk, SMM mengonfigurasi lingkungannya sendiri dengan menyiapkan tabel halaman, mengganggu tabel pengiriman (IDT), dan struktur sistem lainnya. SMM mewakili permukaan serangan signifikan yang dapat digunakan oleh kode berbahaya untuk membahayakan atau menghindari perlindungan OS yang diaktifkan melalui Keamanan berbasis Virtualisasi (VBS). Untuk membantu mengurangi bahaya yang ditimbulkan oleh SMM, fungsionalitas dalam SMM dapat secara konseptual dibagi menjadi infrastruktur inti SMM dan driver SMM sebagai berikut:

  • Inti SMM: Kode yang umum untuk semua implementasi SMM yang melakukan tanggung jawab arsitektur dan infrastruktur

  • Driver SMM: Kode yang ditulis untuk menyelesaikan tugas khusus platform di SMM

Beberapa momen utama dalam siklus hidup SMM adalah sebagai berikut:

  1. Ketika fondasi SMM (atau inti) didirikan – Beban Program Awal SMM (IPL)

  2. Ketika driver SMM dimuat - disebut pengiriman driver SMM

  3. Ketika entri ke SMM terjadi – melalui Gangguan Manajemen Sistem (SMI)

Beban Program Awal SMM (IPL)

CPU memiliki fitur khusus yang memberikan kode SMM hak istimewa tingginya dan membantu melindunginya. Misalnya, mekanisme didefinisikan untuk memasukkan SMM melalui peristiwa perangkat lunak atau perangkat keras, instruksi CPU digunakan untuk kembali dari SMM, dan beberapa register didefinisikan untuk mengontrol akses dan mengunci konfigurasi SMM. Banyak dari register kontrol ini dikonfigurasi oleh kode SMM IPL untuk membatasi akses ke area memori tempat kode dan data SMM disimpan (disebut SYSTEM Management RAM atau SMRAM).

Karena area SMRAM berada dalam memori utama (DRAM), area tersebut tidak dapat dibuat sampai DRAM diaktifkan selama boot. PROSEDUR pengaktifan DRAM bervariasi per vendor silikon tetapi beberapa megabyte kode dapat berjalan langsung dari cache CPU LLC (termasuk kode yang menginisialisasi DRAM) sebelum memori utama tersedia.

Firmware FASR membawa titik IPL SMM lebih awal dalam boot daripada sebagian besar sistem lainnya. Ini mengurangi peluang penyerang harus merusak proses ini dan mengendalikan sistem sebelum SMM disiapkan. Untuk lebih memahami hal ini dan peningkatan lain yang dilakukan pada SMM di firmware FASR, kita perlu mempelajari lebih lanjut tentang proses boot firmware.

Boot Platform Initializations (PI) di firmware UEFI

Firmware PC modern dibangun di sekitar banyak spesifikasi. Spesifikasi UEFI mendefinisikan antarmuka antara sistem operasi yang sesuai dengan UEFI seperti Windows dan firmware pada perangkat. Spesifikasi lain yang disebut Spesifikasi Inisialisasi Platform (PI) mendefinisikan cara driver firmware dibangun dan merinci proses boot itu sendiri. Pada tingkat tinggi, Spesifikasi UEFI dapat dianggap sebagai salah satu standardisasi yang memungkinkan satu gambar Windows untuk bekerja dengan begitu banyak perangkat yang berbeda, dan Spesifikasi PI dapat dianggap sebagai salah satu standardisasi yang memungkinkan begitu banyak gambar firmware dari vendor perangkat keras yang berbeda untuk bekerja sama. Kedua spesifikasi dipertahankan oleh Forum UEFI.

Spesifikasi PI mendefinisikan fase boot dan driver mana yang ditulis ke fase boot. Selama boot firmware, setiap fase menyerahkan ke fase berikutnya dan, dalam kebanyakan kasus, driver dari fase menyerahkan tidak lagi digunakan dan hanya data penting yang diteruskan ke fase berikutnya sehingga dapat melanjutkan proses boot. Fase boot dapat diringkas sebagai berikut:

  1. SEC – Dapatkan kontrol di vektor reset CPU dan transisi dari rakitan ke kode C untuk memuat PEI

  2. PEI – Menginisialisasi status sistem untuk memuat DXE dan menginisialisasi DRAM

  3. DXE – Lakukan inisialisasi sistem yang tersisa, yang mencakup penyediaan dukungan BDS perlu memuat sistem operasi

  4. BDS – Temukan opsi boot untuk boot saat ini (misalnya, pemuat boot OS) dan coba boot opsi tersebut

  5. OS – Kernel sistem operasi

Melindungi Beban Program Awal SMM (IPL)

Firmware sesuai spesifikasi PI UEFI tradisional memuat IPL SMM dalam fase boot DXE. Firmware FASR memuat SMM IPL dalam fase boot PEI. Trusted Computing Base (TCB) untuk sistem adalah serangkaian mekanisme perlindungan total yang melindunginya, termasuk perangkat keras, firmware, dan perangkat lunak. Dengan memindahkan IPL SMM dari DXE ke PEI, seluruh fase DXE (yang merupakan lingkungan yang lebih besar dan lebih kaya daripada PEI) dihapus dari TCB. Diagram berikut menunjukkan SMM IPL yang dipindahkan sebelumnya dalam proses boot UEFI.

S M M I P L dipindahkan sebelumnya dalam proses boot UE F I

Kode PEI dan DXE dijalankan pada ring 0 dan tidak bertahan (dengan beberapa pengecualian) ke dalam sistem operasi. Kode SMM dijalankan pada hak istimewa yang lebih tinggi daripada ring 0 (dan hypervisor) dan bertahan ke dalam sistem operasi, sehingga tidak memungkinkan kerentanan DXE berdampak pada pembentukan SMM mengurangi permukaan serangan sistem secara keseluruhan. Selain itu, karena SMM diluncurkan sebelumnya dalam proses boot, bit kunci diatur untuk membantu melindungi SMM dapat diaktifkan sebelumnya dalam boot, semakin meminimalkan jendela penyerang untuk membahayakan SMM.

Melindungi proses pengiriman driver SMM

Dalam Spesifikasi PI, dua mode SMM didefinisikan: MM Tradisional, dan MM Mandiri. MM tradisional setara dengan model perangkat lunak SMM yang secara historis digunakan dalam firmware yang mematuhi PI, yang merupakan sebagian besar firmware UEFI di industri. MM Mandiri adalah mode yang relatif baru yang merevisi model historis untuk meningkatkan keamanan lingkungan SMM dan mencegah kesalahan umum yang dilakukan dalam implementasi MM Tradisional yang menyebabkan banyak tantangan portabilitas dan keamanan selama bertahun-tahun.

Firmware FASR beroperasi secara eksklusif dalam mode MM Mandiri. Ini memungkinkan firmware FASR untuk mengikuti pendekatan disiplin untuk eksekusi perangkat lunak di SMM. Begitu banyak kerentanan berbasis SMM saat ini disebabkan oleh praktik buruk yang diizinkan dalam kode SMM di MM Tradisional yang hanya dapat dihapus di MM Mandiri. Pada tingkat tinggi, ini terjadi karena—dalam model MM Tradisional—driver SMM dikirim dua kali, sekali oleh dispatcher DXE di ring 0, dan sekali lagi oleh dispatcher SMM di SMM. Ini memberi kesempatan yang cukup untuk kode driver yang dijalankan di lingkungan DXE untuk cache pointer ke sumber daya di luar SMRAM yang tidak boleh mereka akses setelah titik masuk kembali. Serangan yang bergantung pada kode SMM untuk memanggil kode di luar SMM sering disebut sebagai "serangan panggilan SMM".

Melindungi entri ke SMM

Data diteruskan ke handler SMI melalui struktur yang disebut "buffer komunikasi". Handler SMI bertanggung jawab untuk memvalidasi apakah data memenuhi persyaratan tertentu di titik masuknya. Windows SMM Security Mitigation Table (WSMT) adalah salah satu mekanisme yang digunakan untuk membantu mengurangi penangan SMI yang tidak dicentang ancaman berpose ke Keamanan berbasis Virtualisasi dalam sistem operasi. Microsoft telah berkontribusi kode ke proyek TianoCore untuk meningkatkan validasi buffer komunikasi. Selain menerapkan kedua teknik ini, kode FASR juga menerapkan perlindungan akses memori yang ketat, memungkinkan kode SMM untuk hanya mengakses rentang memori yang diizinkan secara eksplisit.

Supervisor Mode Manajemen (Supervisor MM)

Kode inti SMM umum dan dibagikan dengan minimal hingga tidak ada perubahan antar sistem. Permukaan serangan yang diberlakukan oleh SMM dapat sangat dikurangi dengan memperkenalkan pemisahan hak istimewa ke lingkungan SMM. Untuk itu, firmware FASR mencakup Supervisor SMM yang dijalankan di MM Mandiri. Ini menghasilkan lingkungan SMM yang terdefinisi dengan baik dengan TCB minimal yang memiliki tingkat hak istimewa yang diberlakukan dari pembuatan. Mm Supervisor menempatkan pembatasan pada akses port IO, akses Model Specific Register (MSR), akses MMIO, akses status penyimpanan CPU, dan instruksi yang diizinkan di lingkungan SMM. Kebijakan Supervisor SMM digunakan untuk mengonfigurasi detail yang tepat tentang sumber daya perangkat keras apa yang akan dibatasi, dan detail pasti tersebut dapat berubah per pembuatan silikon.

Kebijakan baru-baru ini beralih ke pendekatan tolak secara default yang secara signifikan mengurangi sumber daya perangkat keras yang tersedia untuk dikodekan di luar Pengawas SMM. Supervisor ini beroperasi tanpa dependensi perangkat keras pada kemampuan perangkat keras apa pun yang biasanya tidak ditemukan di PC modern.

Mm Supervisor digunakan di FASR adalah sumber terbuka dan tersedia di Repositori Supervisor Project Mu MM.

Kepatuhan sistem FASR dengan persyaratan PC inti aman

Tabel berikut menunjukkan pilar keamanan yang luas atau tujuan PC Secured-core, dan bagaimana sistem FASR yang melakukan booting di jalur bersertifikat dapat mencapai persyaratan PC Secured-core:

Manfaat Keamanan Fitur keamanan di PC Secured-core
Membuat akar kepercayaan yang didukung perangkat keras Boot Aman
Modul Platform Tepercaya 2.0
Perlindungan Akses Memori Langsung (DMA)
Pertahankan dari serangan tingkat firmware (lihat catatan di bawah) System Guard Secure Launch (D-RTM) atau S-RTM (FASR FW)
Isolasi Mode Manajemen Sistem (SMM) atau MM Mandiri dengan Mm Supervisor (FASR FW)
Lindungi OS dari eksekusi kode yang belum diverifikasi Integritas Memori (juga dikenal sebagai HVCI)
Memberikan verifikasi dan perlindungan identitas tingkat lanjut Windows Hello
Melindungi data penting jika perangkat hilang atau dicuri Enkripsi BitLocker

Jika sistem tidak memiliki kemampuan keamanan tingkat lanjut untuk mendukung D-RTM, persyaratan perlindungan firmware dapat dipenuhi menggunakan kombinasi S-RTM dan MM Mandiri dengan Mm Supervisor, yang keduanya ditawarkan oleh firmware FASR.

Ringkasan

Ini adalah beberapa investasi yang dilakukan Microsoft untuk mengatasi meningkatnya jumlah serangan firmware yang lazim di seluruh industri saat ini. Dengan menggunakan kode sumber terbuka untuk perubahan ini, kami memberdayakan mitra kami untuk menggunakan beberapa manfaat keamanan ini yang pada gilirannya akan menguntungkan ekosistem dan industri yang lebih luas.

Tujuan utama dari inisiatif PC Secured-core adalah untuk membantu memastikan bahwa pelanggan memiliki akses ke beberapa kemampuan keamanan paling canggih yang tersedia untuk PC Windows. Dengan beberapa perubahan firmware ini, kami selangkah lebih dekat untuk mewujudkan tujuan tersebut, dan telah memperbarui persyaratan perlindungan firmware PC Inti Aman untuk mencerminkan penyertaan ini. Pelajari selengkapnya tentang PC Secured-core di sini.