Artikel terbaru meminta persiapan materi ini " Bug driver kartu video dapat mengungkapkan apa yang dilihat dalam mode penyamaran ." Artikel ini lahir setelah publikasi cara sepele untuk menampilkan gambar milik proses (termasuk dihentikan), bahkan mungkin memiliki klaim untuk melindungi informasi.Karena saya juga terlibat dalam pengembangan driver grafis, secara kebetulan, saya akan mencoba menjelaskan secara singkat apa yang salah dengan pembuat laporan bug asli, tanggung jawab masalahnya dan bagaimana cara menyelesaikannya.
Terlepas dari sistem operasi, API sistem terkait, dan antarmuka aplikasi untuk mengembangkan aplikasi grafis, driver kartu video yang sewenang-wenang menyelesaikan tugas-tugas di seluruh sistem berikut:- Inisialisasi pengontrol layar ( mengatur mode video, mengelola porta GPU, membentuk satu / beberapa gambar independen, ... );
- Manajemen memori yang dapat dialamatkan ( antrian perintah, pengalamatan linier / ubin, alokasi permukaan, tabel terjemahan alamat, ekstensi bukaan PCI, ... );
- Akselerasi 2D ( kursor, lapisan perangkat keras, kunci alfa / kroma, ROP, primitif, ... );
- Akselerasi 3D ( OpenGL, OpenGL ES / EGL, OpenVG / EGL, OpenCL, Open * );
- Video decoding / pemutaran audio / pengurangan EDID / kompresi bingkai buffer, ...
Pendekatan terhadap solusi dari tugas-tugas yang diterapkan pada setiap tahap telah lama direduksi menjadi praktik yang sudah mapan. Ini hanya menjelaskan kemampuan reproduksi masalah yang ditunjukkan pada perangkat dari berbagai produsen. Ke depan, saya dapat mengatakan bahwa Anda bisa mendapatkan efek yang sama pada pengontrol Intel. Penulis laporan bug ditentukan secara akurat dalam kerangka solusi yang menimbulkan masalah - manajemen memori yang dapat dialamatkan.
Manajemen memori
Entitas utama yang dioperasikan pengemudi pada tahap ini adalah permukaan. Permukaan umumnya disebut potongan video atau RAM terus menerus yang digunakan untuk membentuk gambar oleh beberapa aplikasi. Untuk pengendali yang tidak memiliki memori sendiri, sumber daya yang dialokasikan dari RAM dapat dialamatkan melalui tabel terjemahan alamat (Graphics Translation Table, GTT). Jika tidak, gambar hanya dapat ditampilkan saat menyalin permukaan ke dalam memori video, baik melalui pengontrol DMA, jika ada, atau karena sumber daya CPU.Bahkan, bahkan pengendali dengan memori diskritnya sendiri dalam banyak kasus juga mengatasinya melalui GTT, karena dengan cara ini dimungkinkan untuk membuat ruang alamat virtual dengan analogi dengan prosesor pusat TLB untuk menyediakan pengalamatan linear atau ubin. Metode pengalamatan dalam setiap kasus menentukan driver dan tidak ada perbedaan mendasar di antara mereka dalam kerangka kerja artikel ini.Contoh pengalamatan ubin di memori video dari artikel sumber Driver pengontrol grafis adalah antarmuka untuk OS ke fungsi GPU, tidak lebih. Semua tugas untuk memastikan perlindungan informasi ditugaskan ke tingkat yang lebih tinggi yang bertanggung jawab untuk ini. Untuk ini, driver memiliki semua fungsionalitas yang tersedia, akan ada keinginan untuk menggunakannya.Jadi, atas permintaan beberapa driver klien, OS cadangan (mengalokasikan) satu set permukaan untuk itu. Karena, menurut penulis, fragmentasi gambar relatif jarang, kami dapat berargumen bahwa pengalamatan ubin tidak sering digunakan dalam kasus ini. Dengan pengalamatan linier, setiap permukaan ditandai terutama dengan offset dari awal ruang alamat virtual memori pengontrol. saat mengalokasikan memori, driver mengembalikan OS persis offset ini, yang sesuai dengan blok memori bebas yang dapat mengakomodasi permukaan dengan karakteristik yang diminta oleh perangkat lunak aplikasi. Dalam hal ini, pengemudi hanya melakukan tindakan berikut: memodifikasi GTT untuk penggunaan lebih lanjut dari halaman memori virtual, memonitor kepatuhan dengan persyaratan untuk penyelarasan alamat fisik,mendefinisikan mekanisme akses perangkat lunak aplikasi ke permukaan (bukaan PCI / GPU, berdasarkan alamat fisik di luar bukaan, ekstensi GTT on the fly), menyimpan sebagian memori untuk kebutuhannya sendiri.Berdasarkan hal tersebut di atas, kita dapat menyimpulkan bahwa memiliki informasi tentang jumlah total memori pengontrol yang tersedia dan karakteristik permukaan yang diperlukan, penentuan offset untuk semua pengontrol dapat diselesaikan dengan cara yang sama. Dalam praktiknya, inilah yang terjadi (dipandu oleh pengalaman dengan berbagai sistem operasi mirip-unix): OS menyediakan layanan sistem / pustaka yang menyimpan daftar blok memori yang sudah digunakan dan memungkinkan Anda untuk dengan cepat menghitung offset pertama yang tersedia untuk cadangan logis dalam pustaka ini. Pada saat yang sama, memiliki informasi dari pengemudi tentang mekanisme akses ke blok memori, OS umumnya memungkinkan perangkat lunak aplikasi dibentuk pada alamat fisik yang sama dari permukaan yang dibagi / berpotongan.Jika pengemudi tidak secara eksplisit mengontrol permukaan, lalu bagaimana akselerasi dilaksanakan?. - , , ( ), .
( ) , ( ), .
Kembali ke masalah semula
Tentunya pada titik ini, banyak yang sudah menebak apa yang menjadi kritik. Ketika menjalankan berbagai aplikasi, OS meminta permukaan driver video untuk kebutuhan mereka dan menggunakannya kembali ketika memori menjadi bebas (pemutusan proses). Pada saat yang sama, pengemudi tidak dapat menyadari bahwa beberapa blok memori memerlukan pengaturan ulang segera, karena memiliki persyaratan keamanan tertentu dan tidak memiliki tautan lain. Mengenali memori itu sendiri adalah tugas sepele dari perangkat keras mengisi persegi panjang.Faktanya, tes yang ditulis untuk mempublikasikan laporan bug adalah mubazir. Dalam kasus umum (ketika memori video masuk ke dalam bukaan PCI / GPU), tidak ada API aplikasi yang diperlukan untuk sistem mirip-unix. Cukup menghubungi / dev / mem menggunakan offset yang diketahui dari output utilitas "lspci".Untuk pengontrol Intel, situasinya berbeda, tetapi tidak banyak. Karena pengontrol tidak memiliki memori sendiri, GTT dibentuk dengan cepat dengan alokasi memori dari RAM. Ketika mengalokasikan kembali permukaan, mungkin saja tidak beruntung dengan lokasi sebenarnya dari blok RAM, mengingat bahwa dalam hal ini mekanisme pengalamatan virtual OS sudah memainkan peran yang menentukan.Ada beberapa solusi, dan saya percaya bahwa kesimpulannya akan jelas:- Semua pabrikan driver harus menerapkan fungsionalitas yang berlebihan untuk menyimpan informasi tentang permukaan yang ada ( pertanyaan tentang mengendalikan permukaan bersama tetap terbuka );
- OS harus memantau kebutuhan aplikasi ini atau itu untuk merapikan ( ini adalah tanda tertentu dari permukaan yang dilindungi, atau pemberian berlebihan pada permukaan apa pun baik dalam RAM maupun dalam memori video );
- Perangkat lunak aplikasi harus membersihkan dengan benar setelahnya, karena ia mengklaim terlibat dalam keamanan informasi.
Semoga catatan itu menarik.