Mengikuti artikel minggu lalu tentang pengembang Linux yang mengincar mitigasi keamanan “DOITM” baru untuk CPU Intel terbaru berdasarkan panduan dari Intel seputar instruksi Data Operand Independent Timing (DOIT) dan kemudian terungkap bahwa mode DOIT tidak harus selalu pada, pernyataan yang lebih panjang dari salah satu insinyur Linux Intel telah diterbitkan menyimpulkan keyakinan saat ini dan kemungkinan kernel Linux di sekitar DOIT(M). Seperti yang dijelaskan dalam artikel Phoronix sebelumnya tentang masalah ini, berdasarkan panduan yang diterbitkan tahun lalu oleh Intel seputar DOIT, prosesor Intel baru-baru ini dan yang akan datang tidak dijamin “waktu yang konstan” sehubungan dengan operan datanya kecuali bendera register khusus model khusus diatur. Hal ini menimbulkan kekhawatiran terutama seputar kode kriptografi untuk Linux bahwa tidak ada lagi jaminan waktu yang konstan dan bahwa waktu eksekusi instruksi dapat bervariasi tergantung pada data yang dioperasikan. Eksekusi waktu yang konstan diperlukan untuk menghindari kemungkinan serangan saluran samping. Namun dalam mengaktifkan bendera Intel baru untuk memastikan waktu yang konstan, ia hadir dengan implikasi kinerja yang diakui. Implikasi kinerja dengan prosesor Intel generasi sekarang tidak terlalu signifikan dari pengujian awal yang saya lakukan, tetapi dokumentasi Intel menunjukkan hal itu dapat meningkat di masa mendatang. Dengan penanganan Linux dalam bentuknya saat ini adalah tentang selalu mengaktifkan Mode Waktu Independen Operan Data, tetapi kemudian terungkap adalah rekomendasi yang tidak selalu aktif. Mitigasi DOITM dengan patch kernel Linux out-of-tree saat ini yang memicu diskusi baru-baru ini mengenai instruksi Intel DOIT. NbspInsinyur Intel Linux lama, Dave Hansen, menyediakan postingan LKML yang lebih panjang tentang fungsi ini setelah berbagai diskusi internal di perusahaan. Penjelasan publik yang panjang dan wawasan ekstra dipublikasikan ke milis kernel. Untuk kenyamanan Anda, ini disematkan di bawah ini. “Ini adalah upaya untuk memastikan bahwa setiap orang yang peduli tentang perilaku DOITM memiliki semua informasi yang sama dengan orang-orang Intel sebelum kami membuat keputusan tentang implementasi kernel. Ini dia… Latensi eksekusi dari instruksi DOIT tidak bergantung pada nilai operan data pada semua prosesor Intel yang didukung saat ini. Ini termasuk semua prosesor yang menghitung dukungan DOITM. Tidak ada rencana untuk prosesor apa pun di mana perilaku ini akan berubah, meskipun arsitektur DOITM secara teoritis mengizinkannya. Jadi, apa titik DOITM di tempat pertama Latensi eksekusi tetap tidak berarti bahwa program secara keseluruhan akan memiliki latensi keseluruhan konstan DOITM saat ini memengaruhi fitur yang tidak memengaruhi latensi eksekusi tetapi mungkin, misalnya, memengaruhi latensi program secara keseluruhan karena efek samping prefetching pada cache. Bahkan dengan latensi eksekusi instruksi tetap, efek samping ini dapat menjadi masalah terutama bagi paranoid. Saat ini, fitur yang terpengaruh adalah: * D ata Dependent Prefetchers (DDP) * Beberapa Fast Store Forwarding Predictors (FSFP). Ada kontrol untuk fitur tersebut, termasuk spec_store_bypass_disable=. Beberapa perangkat lunak paranoid mungkin sudah memiliki mitigasi yang merupakan superset dari DOITM. Selain itu, DDP dan FSFP juga dirancang untuk membatasi keburukan saat melewati batas hak istimewa. Silakan lihat dokumen tertaut untuk detail lebih lanjut. Itu pada dasarnya adalah sisi Intel. Semua orang harus memiliki semua latar belakang yang saya miliki. Sekarang kembali ke mode pengelola… Jadi, singkatnya, saya rasa perpustakaan crypto semua orang tidak rusak hari ini ketika DOITM=0. Saya tidak berpikir mereka akan _menjadi_ rusak dalam waktu dekat. Kemana kita pergi dari sini? Ada beberapa pilihan: 1. Terapkan tambalan di utas ini, selalu atur DOITM=1. Saat ini, ini mengurangi paparan terhadap DDP dan FSFP, tetapi mungkin hanya untuk ruang pengguna. Ini mengurangi paparan terhadap prediktor masa depan di bawah payung DOITM dan juga dari Intel yang berubah pikiran. 2. Abaikan DOITM, biarkan ke hardware default DOITM=0. Hari ini, ini mungkin hanya mengarahkan orang untuk menggunakan mitigasi yang relatif berat (seperti SSBD) jika mereka ingin DDP/FSFP dinonaktifkan. Itu juga membuat Linux terpapar pada Intel yang berubah pikiran tentang rencana masa depannya. 3. Terapkan tambalan di utas ini, tetapi biarkan DOITM=0 sebagai default. Ini memungkinkan orang-orang mengaktifkan DOITM pada saat itu juga jika diperlukan. Ada beberapa pilihan gila lainnya seperti menambahkan ABI untuk mengaktifkan DOITM untuk ruang pengguna, tapi saya tidak yakin itu layak untuk didiskusikan. #1 jelas merupakan satu-satunya cara jika arsitektur DOITM tetap apa adanya. Ada pembicaraan tentang membuat perubahan, seperti menghapus sepenuhnya ide latensi eksekusi variabel. Tapi itu proses yang lambat dan akan menjadi non-starter jika *siapapun* (seperti OS lainnya) bergantung pada definisi DOITM yang ada. Kecenderungan saya adalah menunggu beberapa minggu untuk melihat ke arah mana DOITM menuju dan apakah definisi tersebut kemungkinan besar akan berubah. Adakah yang merasakan urgensi yang lebih besar?” meskipun dalam beberapa minggu ke depan akhirnya apa yang diputuskan oleh pengembang kernel Linux hulu tentang fitur/mitigasi keamanan Intel ini.
Itulah berita seputar Penjelasan Terperinci Tentang Mode DOIT Intel, Kemungkinan Opsi Untuk Penanganan Linux, semoga bermanfaat. Disadur dari Phoronix.com.